Tuesday, 30 June 2015 18:50

The Mythical Man-Month: Essays on Software Engineering

Written by 
Rate this item
(1 Vote)
The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition

Add To Cart

Author:Frederick P. Brooks Jr.
Publisher: Addison-Wesley Professional
Released: August 1995
Type: Softcover
Pages: 336

Not too long ago I had coffee with fellow tweep, Peter Kretzman, at the Zeitgeist Coffee in Seattle. We had a wonderful conversation and shared stories, philosophies, and impressions. In the process we stumbled upon a common literary love—The Mythical Man-Month by Frederick Brooks. I read it for the first time last summer and Peter reads every few years. We both extolled the virtues of the book and lamented at the fact that so many of the items Brooks brings up continue to plague us today.

If you have not read the book (I strongly recommend you do), it discusses the lessons learned from building the IBM System/360. Yes, the 360. I was still in grade school, and many readers were less than a glimmer in your parent's eye. Amazingly the book continues to sell, topping over 250,000 copies in print, and is still perfectly relevant. That is also the sad part, it appears we have not learned from past failures.

Silver Bullets

The core to building systems is making sure the requirements meet the business needs. Tools can help with the coding and even aligning requirements but none of them will improve productivity an order of magnitude. Neither can they ensure the requirements are the correct. This is the most difficult, time consuming, and error prone portion of any system development project. It still takes people talking to people, gathering the correct requirements, and turning them into a usable system.

Silver-bullet tools cannot solve issues on a project. They can address some area but leave others exposed and vulnerable. As the colloquialism goes, they are just trading the devil we know for the devil to be reckoned with.

Progressively Sliding Schedules

"How does a project get to be a year late?
...One day at a time"

A day here, a day there, projects slowly drift later and later. Eventually, someone looks to see the project is months or years late. Realization that the project is late only happens after senior management has the epiphany there is an issue. They set off the alarms as if it happened overnight. However, a project timeline jumping by months on a single problem is rare, if non-existent. Even then, the issue that caused the delay does not manifest without warning—it is a risk that should have been known well in advance. People did not properly identify and understand the threats in the project.

Internal Scope Creep

Scope creep introduced by the project team, not the customer, is the stealthy stalker, prowling inside the project ready to swell scope. A form of this, the second system effect, Brooks defines as when a team working on a product for the second time includes "frill after frill and embellishment after embellishment that occur to" them in the first pass of working on the system. At which time the features were only noted, their implementation delayed due to the newness with the product. The second system will bear the brunt of the additional scope as team members add it devoid of any formal change process.


It all boils down to people. People cause the schedule to slide, they add scope, and they are over-optimistic. The solution is a team that can realize there is a problem, identify a solution, and implement a solution. Teams need leaders, guiding them through difficult decisions and defining what is needed rather than what is wanted.

Buy it now!

Read 6255 times Last modified on Monday, 13 July 2015 14:20

Leave a comment