« March 2006 | Main | October 2006 »

August 27, 2006

Too Many Developers

This problem surely does not happen to the most projects, but if it happens, you should solve it quickly, otherwise the productivity of the hole team drifts to zero…

If you have the problem having too many developers for the project, the communication overhead gets too high and the most effort goes to synchronizing development status, communication etc. Here are my top four methods to solve this problem, that probably most bigger companies have:

Place 4. Fire superfluous personnel

If your company is financially successful and growth-oriented it is probably not the option. It is not only unsocial. It’s barely possible for european companies and societies, that are consensus-oriented and strive for harmony. And downsizing is demotivating for the remaining staff.

Place 3. Pair programming

Your situation is immediately two times better as before, because you only have the half of programming-atoms. A positive side-effect, if one employee gets sick or goes for vacation, the other half of the “development atom” can continue development. Let one of the two try new technologies or new library from time to time. Don’t let all the developers play with the newest ruby version or install the new WebSphere.

Place 2. Divide the project into the parts

… in such way, that you eliminate the common code base, common source control management, lengthy build cycles and all the problems you have with big (mesured in the number of active developers) project. If you are developing an enterprise application, then eleminate interdependencies and use some sort of loose coupling, for example, web services for communication between the parts of your application. Don’t use EJB for that or CORBA or some sort of RPC. Well define the messages in advance. Regular end-to-end test during the whole development would be very advantageus. It es probably better to directly use REST instead of XML Web Services as the latter leads to RPC-style-thinking.

Place 1. Competing teams

Divide all your staff into two parts and let them develop products independently. Afterwards you can compare the solutions und choose the best. Let them use different platforms and technologies so if there are some unsolvable problems an one team stucks with one of bleeding edge technologies, the other can still continue. Let one team do the stuff in ruby on rails if they want. Then they are probably 10 times more productive. If at the end one of this open source frameworks gets abandoned because key developers are poached by google or microsoft, you still have the chance that the other team finishs their EJB-development.

Posted by VladimirDobriakov at 3:50 PM