The Mythical Man-Month by Frederick P. Brooks Jr.

Originally written in 1975 and then revised in 1995, I think this book truly withstands the test of time for the field of software development. It isn’t full of checklists and to-dos that are guaranteed to make your projects work [no snake-oil here], but rather wisdom from an experienced software project manager. Several of the chapters are actually stand-alone essays and this book simply collates them in a logical manner. Most of the information is easy to read and moves pretty quickly, in fact, I actually finished it in about 10 days. As a busy person with several personal/professional interests and responsibilities, that means a lot to me because then I actually read the book instead of letting it drag out for months without ever finishing it.

Your first reaction might be “the book is more than 30 years old, what could possibly be relevant towards today’s technologies?” You’re right to be curious about that, as was I, since technology has made so many changes in the past 30 years. The wonderful thing about this book is that even in the initial publication the author recognizes the extreme rate at which technology advances and addresses it constantly. For the most part, Brooks speaks to technology as an idea/concept instead of talking directly to this or that programming language. That perspective allows the conversations to transcend most technological limitations that would have been present had he addressed explicit hardware or software technologies.

Although the title is The Mythical Man-Month, Brooks delves into several aspects of software development and highlights the challenges we face on a daily basis. Here are several points from the book that I found interesting.

Using the concept of a man-month as a unit of estimating time to complete a project is really a fallacy. It is often assumed that men and months are “interchangeable commodities,” but that only holds true if “a task can be partitioned among many workers with no communication among them.” Adding more developers to a project will not result in it being completed sooner, in fact, most of the time it will increase the time due to the added complexities of communication.

Time estimation is the Achilles heel of software development projects [my words, not Brooks] because “our techniques of estimating are poorly developed” and “fallaciously confuse effort with progress.” Based on my 1-1/2 years of limited experience this still holds true today.

The surgical team concept as proposed by Harlan Mills – Each programming team should consist of a surgeon, copilot, administrator, editor, two secretaries, program clerk, toolsmith, tester and language lawyer. Some of the role responsibilities are obvious by their name, while the others are defined in the book. Suffice it to say that I equate this to the current process of agile programming with small teams.

The Second-System Effect: As he designs the first work, frill after frill and embellishment after embellishment occur to him. These get stored away to be used ‘next time.’ …This second is the most dangerous system a man ever designs…. The general tendency is to over-design the second system…the result…is a ‘big pile.’

In the chapter, Why Did The Tower of Babel Fail?, Brooks states that lack of communication and the subsequent lack of organization are the culprits. He applies this theory to programming projects and how the increase of workers will drastically increase the likelihood of miscommunication, hence failure. Oh so true in my experience.

Catastrophic failures can be avoided by reducing a boss’ role conflict. They must:

Distinguish between action information and status information. He must discipline himself not to act on problems his managers can solve, and never to act on problems when he is explicitly reviewing status.

If front-line managers know their manager will not over react during status reports then they are much more likely to be honest in those status reports. Top-level management needs to trust their line managers to resolve conflicts and react only when asked to do so or when they absolutely have to.

One of the most interesting ideas presented in the chapter, No Silver Bullet, was that high-level languages (such as .NET and Java today) would not be a large breakthrough in the software development field. Brooks hypothesizes that “at some point the elaboration of a high-level language becomes a burden that increases, not reduces, the intellectual task of the user who rarely uses the esoteric constructs.” I see his point, but I must disagree to an extent. While high-level languages obfuscate several fundamental concepts in software development they have broken down some of the traditional barriers by allowing non-CS graduates [like myself] to enter the field and be successful. I don’t have a background in C or C++, but I am learning how to be a good developer through the massive resources available to me. Regardless of that, I was able to jump in and be productive within a very short time using .NET because I am a quick study and didn’t have to learn memory management or object oriented programming first. Just to be clear, that first application I wrote looks un-godly awful according to my standards today, but my point is that I was able to do it…not how well it was done.

I highly recommend this book for both software developers and project managers. Actually, I would like everyone involved in software development (developers, program managers, architects, testers, people managers, etc.) to read this book!