The Mythical Man Month: Still Applicable Today

I recently read Fred Brooks' "The Mythical Man Month" 20th anniversary edition. It's a collection of essays on software engineering, mostly from a management perspective, on topics such as what sort of teams work well for writing software, what management mistakes tend to be made, and what hope there is for speeding up the process of writing software. Definitely worth a read.

Although most of the essays were written in the 1970s, I came away with some interesting conclusions which are still applicable today. In particular:

• Adding man-power to an already late software project will just make it later (otherwise known as Brooks' Law, this effectively expresses the non-equivalence of men and months).
• Constructing programs for commercial release takes about nine times as long as for private use, because of adding generality, integration, and testing.
• Teams modelled on surgical teams work well. One lead programmer, supported by a subordinate programmer, both of whom know all the code in their module. They are supported by administrative and QA staff. This means that in a team of up to 10 (perhaps fewer now?) only two are really programming, the remainder take care of all the rest.
• Architecting software and implementing software should be separate. This allows the architect to think clearly (and cleverly) about the design, and the implementer to intelligently make that design reality. Both are hugely important and demanding roles.
• Ultimately, there needs to be someone in control for the system to be architecturally sound as a whole: hence there is a tree-like chain of command. However, socially (for communication) relationships should be more of a network, not having to pass through intermediaries in the tree.
• The second system built by a team is likely to be bloated.
• Ensure that architectural decisions are communicated to all the team. This includes telephone/e-mail clarifications made to implementers (use a wiki?)
• Documentation writing for the entire system should be the work of just one or two people, to ensure consistency.
• In a team, the roles of producer and architect are unlikely to both be assigned to a single person. The former is a project manager (finance, schedule), the latter is the technical director.
• Giving teams CPU cycles/memory bytes/bandwidth allocations for their modules avoids overall bloat.
• Flowcharts for software are only useful for the most high-level of view points.
• Plan to throw one interation of software away, i.e. be prepared to construct a pilot, show it to the customer, and then re-write from scratch.
• Technical and management staff should have career ladders that have rungs of equal status (office size, salary, administrative support...)
• Get an outside group (not the developers) to analyse the initial specification for holes.
• Have a schedule with well-defined milestones. This avoids developers deceiving themselves as to whether an ill-defined milestone has been reached.
• Have "scheduled" dates and "completion" dates. The former is what the plan says, the latter is what the developer team's manager says is likely to be date of completion. The boss needs to avoid trying to do the team manager's job by suggesting changes to the implementation in order to change the completion date.
• Documentation needs to give a wide overview, then zoom into the detail.
• No silver bullet: it is unlikely that there will be a significant advance in software engineering that reduces the complexity of the process by an order of magnitude, any time soon.

Brooks evaluates the above 20 years later (1996?), finding that they still hold true. They also sound very relevant to me now!