« 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.
- Let the different teams use different development infrastructure as well, don’t force all to use heavy-weight UCM or heavy-weight home-grown build-system.
- Let one light team use subversion and some light-weight build-system.
- Let them do the builds two times a week, not every hour.
Posted by VladimirDobriakov at 3:50 PM