The Mythical Man Month and Other Essays on Software Engineering by Frederick P. Brooks Buy at: Amazon

The classic on running software projects, from the 1950s, 60s and 70s.

This was a book were we set to read at university, but frankly it just wasn't something I was interested in as an undergraduate. Reading it now, I was expecting to be amused by the terminology and the way things worked. There were a couple of things like that, such as the role of "toolsmith" for a project, but on reflection that role probably does still exist in a team, although not explicitly. Unfortunately, or fortunately depending on your point of view, there's a lot that is still very relevant.

I'd describe the book as a series of short essays, many with a pithy take-away point. The most famous concerns the cost of communication, summed up in Brooks's Law: "adding manpower to a late software project makes it later". However, each point is deeper than these widely-quoted laws, giving a background into the origins and the applicability of the laws. Regarding the man-month, Brooks observed that although the cost of a project does depend on the number of people and the number of months, progress does not. "The man-month as a unit for measuring the size of a job is a dangerous and deceptive myth."

One of the problems is that we're terrible at estimating. It's interesting to see that for the System/360 development, the software scheduling estimates that Brooks used worked on the heuristic of: 1/3 planning, 1/6 coding, 1/4 component tests, and 1/4 system tests. But, "[...] false scheduling to match the patron's desired date is much more common in our discipline that elsewhere in engineering. It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived from no quantitative method, supported by little data, and certified chiefly by the hunches of the managers."

Another famous quote is "plan to throw one away; you will, anyhow". Although perhaps not directly relevant today, I feel there's still a lot of truth in it. "System program building is an entropy-decreasing process, hence inherently metastable. Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence". Refactoring should save the day, if you create the opportunity to do some.

There was one point in the book that struck me, that when I read it, I just thought "yes! that's it!". And it's this: "I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good by independent and uncoordinated ideas." (p. 42). That really resonates for me.

Some of the practices have interesting analogies today. For example: "In fact, UML diagraming is more preached than practiced. I have never seen an experienced programmer who routinely made detailed UML diagrams before beginning to write programs. Where organizations standards required UML diagrams, these are almost invariably done after the fact. Many shops proudly use machine programs to generate this 'indispensable design tool' from the completed code." Ok, the original was talking about flow charts where I wrote 'UML diagrams', but I think it rings true.

The retrospective essays, towards the end of the book, written 20 years later more or less show that the lessons still hold up today.

back