Single post
The mythical man-month
The mythical man-month by Frederick Brooks is a now ancient classic on project management, with a focus on programming & systems development. It has excellent advice on the subject which is mostly very relevant today.
Some of the main lessons I took away from this book are:
Time estimates & planning
Time estimates in software projects are often out by a long way. This is in part because not enough time is given to testing. Frederick’s advice is that if a component takes X time to build, it will take 2X time to test, on it’s own. On top of that it will also need another 2X integration testing time in addition to around 2X planning time. This is to say that the original estimate of X is likely to be out by at least a factor of 5.
Team setup
Another issue is that the larger a team, the less productive per-member the team. A team of one will mean ideas, architecture, set-up, bugs and the like don’t ever need to be communicated. Conversely, a team of 100 needs 100 times as many interactions to communicate basic details. Communication time which could be spent working on the problems at hand.
Obviously, some projects will require larger teams, but there is a strong incentive to keep the teams lean. Specifically, in his book, Brooks makes a comparison to a surgical team with one lead architect, a ‘co-pilot’, two team members and a couple of secretaries to deal with the administration.
There is a lot to be said for smaller, leaner teams.
Project overrun
When it looks like a project is over-running, project managers have a tendency to add more resource to the project. This in the end has the counter-productive outcome of taking the existing team off their current tasks to train up the new team-members in the project setup. This doesn’t solve the original problem and instead leads to more burnt man-hours.
The main lesson here is to add new team members early on and to trust the team to deliver later on.
Higher level languages
This was probably the most interesting section/takeaway. I was reading the 20th anniversary imprint of the book, itself now 10 years old. In it, Brooks talks about the incredible development gains made by adopting object-oriented programming languages (specifically, by moving to C++ instead of COBOL, ALGOL or Assembly).
With the subsequent increases in processing speeds, we will probably see similar improvements with functional programming. As per many recent medium articles (cf. Goodbye, Object Oriented Programming), for many projects, OOP is creaking and straining. There are a lot of gains to be made from functional techniques.
Summary
Keeping teams lean can really help companies deliver projects on time and to-budget. This is not just true in I.T. but many other disciplines too, however, it is especially important in I.T. to keep as small as possible. This sounds very close to agile and something I am currently exploring in Robert Martin’s Agile Principles, Patterns and Practices.