Geek Reading, February 2007

I finally have been able to finish reading the classic "The Mythical Man-Month," a collection of essays about software engineering by Frederick P. Brooks, Jr.   This is an old and delightfully anachronistic book which speaks of vestiges such as time-sharing on terminals, and I can't recall a single instance where the author ever once refers to the possibility of a female actually working on a technology project, but certain of Brooks' key points are utterly timeless and remain very valid.

The old joke goes, roughly:  "There are 10 kinds of people in the world; those who know binary, and those who don't."  So, if you know me, you know by now that I am not a programmer.  Brooks' ideas are still very relevant to non-programmers for a whole bunch of reasons:

• you manage software development projects
• you are a stakeholder in software development projects
• you sell services (especially software development services) and need to estimate time and cost, etc.

There are several brilliant essays in this book, but two that all project managers of software projects should be required to read.  The first is "The Mythical Man-Month," where Brooks discusses why software projects are frequently delivered late and over budget.  He identifies five main reasons, and discusses each in detail:

1. estimating techniques, based in assumptions that all will go well
2. estimating techniques that confuse effort with progress and assume that men and months are interchangeable
3. weak managers who lose under pressure their "courteous stubbornness" about realistic estimates
4. poor monitoring of schedule progress (especially relative to other more mature disciplines, such as engineering)
5. the natural and traditional response of adding manpower when schedules slip (no, no, NO!)

This essay was first published in 1975, and I can tell you from experience that it is ALL still relevant in 2007, sadly.

The second essay, "No Silver Bullet," was originally published in 1986 and remains similarly relevant.  The main premise of this essay is that no single development in either technology or management would lead to even a single order-of-magnitude improvement within a decade in productivity, reliability, or simplicity.  Brooks backs his premise with details about both accidental and essential elements of software engineering, and how the former has been improved but the latter remains elusive.

I took heart in some recommendations that Brooks makes on improving the essential parts of software engineering (complexity, conformity, changeability, abstraction), and the fact that I see of them being used in my work on a frequent basis.  His suggestions, summarized:

• exploit the mass market to avoid constructing what can be bought
• use rapid prototyping and plan multiple iterations to establish requirements
• grow (don't build) systems organically, adding functions to systems as they are run, used, and tested
• identify and nurture great designers (related to the classic premise that the great software developer can be as productive as ten average software developers)

While Brooks' prose evokes images of a dapper gentleman wearing a suit and a hat as he goes off to work in his Nash Rambler (smoking Lucky Strikes at his desk, etc.), his arguments are timeless and his advice holds true today. (Note:  The edition of the book I have also captures accompanying critiques and updates, including the author's own revisions over a span of some 20 years as the industry grew up and evolved).

There are many details underlying the summary above, but I highly recommend this that any project manager who runs software development projects keep a copy of these essays close at hand.

Comments

[sadalit]

Great review! It actually makes me want to read the book, but your highlights are so good that I won't feel guilt if I don't get to it for a while.
The point about effort vs. progress is ringing especially true to me right now, as I spend today tackling items on a tasks list. I'm not going to be able to complete them all, but the effort is 100%.
FYI, a 1957 Nash Rambler was my parents 2nd car after they were married; they said it was a big comedown from their nice ('54?) Nash. Its "poor little cousin" in fact, like buying a Yugo after a nice Toyota. No Lucky Strikes involved.