How to develop code

Various project managers have discussed the problems of group development when it comes to programming, of which the most famous is Fred Brooks, better known as the father of IBM's System/360. In his book, "The Mythical Man-Month" (1995, Addison Wesley Longman, Inc), Brooks describes amongst other things the problems project managers run into when treating men and months as interchangeable, particularly when inter-group communication is a requirement. The startling conclusions he comes to include that programmers who have complex relationships with other programs in the same project - that is, they rely on each other to produce their code - will find the time they spent communicating increase as more people are added.

Brooks' formula for this was n (n -1)/2, which means that a project of two programmers will spend an effort of 1 communicating (that might be one hour a week, one hour a day, etc), whereas a project of three programmers will spend an effort of 3 (three times as much time spent communicating as a team of two), four will spend 6 (six times as much), five will spend 10 (ten times as much), and so on. By the time you are at 50 programmers you are at an effort of 1225, which means a team of 50 programmers will pretty much spend more time communicating than working, at which point it is clear that something needs to be changed.

Group intercommunication formulae such as n (n -1)/2 might seem obvious, but few people actually consider how it affects programming teams - this is the magical element that makes The Mythical Man-Month an enduring favourite.

When it comes to how code is actually written, there are a variety of styles to choose from. All the rage right now is Extreme Programming (XP), which favours coding simplicity, verbal communication, rapid prototyping, and constant feedback. The hallmark of an XP project is one that releases a very simple, barely working version of the solution first, then, releasing incrementally different versions, constantly getting feedback and modifying/filling in the system design, until the solution is complete. Many XPers work in pairs; one programmer programs, the other watches and comments. After a while they switch, which forces both programmers to the project code guidelines.

Another popular technique received widespread attention after being quoted by Fred Brooks in The Mythical Man-Month attempts to keep programming in as few hands as possible. The technique, designed by Harlan Mills, has ten people working in each group, of which just two actively contribute code to the project, and of those two only one decides how the solution is designed and implemented.

So, on one hand we have "design a little at first, then let everyone develop - the rest of the design sort itself out", and on the other we have "one person designs, two develop, and everyone else is there to back them up in non-programming ways". The chances are you are likely to find your best solution somewhere in between the two - PHP allows you to rapidly develop a system then fill in the gaps as you go, which lends itself well to Extreme Programming. On the other hand, XP does not scale very well - once you get past ten or twenty developers it starts to deteriorate into a productivity vortex.

Copyright ©2015 Paul Hudson. Follow me: @twostraws.