Fog Creek Software
Discussion Board




Developing in a shared environment

Does anyone know of any good books or web references on the topic of developing software in an evironment shared by many (200+) programmers?  I'm not referring to programmers updating the same code per se, though. 

Image you have a tightly integrated system of many hundreds of processes and databases that have to work together to create a coherent product for the user.  There are many single points of failure in th environment. If I am working on my task foo and it is unstable, the entire environment becomes unstable for all of the developers.  The environment is also complicated enough such that it can be very time consuming to debug what piece has actually failed.  There are multiple development servers each with a copy of the environment, but still few enough such that 50+ developers must be testing/developing on each system.  The complexity of the environment necessates this more than money for machines. 

What I'm looking for is research/books/ideas on how to best manage this.  Currently we partition the machines by group, have dedicated operators, and have systems to  make it easier to see what has failed.  But it's still a nightmare to devlop in.  We are looking to improve this as much as possible...

Frank Corrao
Monday, July 12, 2004


The old standby will work for you:  The Mythical Man-Month.

Then get the "Pragmatic Programmer".

Both are relatively quick reads and should get your juices flowing.

I'd also look into "Test Driven Development" in order to manage the ever-changing and growing code-base, but that will take motivating the team leaders.

KC
Monday, July 12, 2004

Frank:

I am adding you to my prayer list.

Ha, ha, only serious.

This is a very tricky problem. Usually you need to isolate, as much as possible, the different pieces.

So group A uses a stable (maybe not bug free but they know most of what is wrong with it) piece from group B.

Then group B updates less often than every time a new piece of code is checked in.

That's one way.

And of course, automated unit tests for each part.

dot for this one
Monday, July 12, 2004

Interesting article. Got me thinking.

Could managers who shoot down every idea from their staff feel threatened by them.

frustrated
Monday, July 12, 2004

*  Recent Topics

*  Fog Creek Home