Many IT pros have read Frederick P. Brooks’ book The Mythical Man-Month: Essays on Software Engineering. The book is a collection of 15 essays published in 1975 that address issues encountered in computer development projects. Brooks, known as “the father of the IBM System/360,” offers hard-earned lessons learned at IBM about computer project management problems and solutions. Can technical leads take these “ancient” lessons to the bank today? They sure can. Here are a few examples and their current relevance.

You want it when?
Brooks’ major premise of the title essay, The Mythical Man-Month, focuses on the mistaken idea that lagging software project deadlines can be met by simply assigning more developers to the project. Brooks addresses why project managers often come up with incorrect estimates that push the project to the critical stage. The main reasons for concern are estimation tools and techniques.

From my experience, even though these estimation tools and techniques have improved immensely, project managers still try to please management with overly optimistic estimates. Another problem still wrestled with today is the collection of historical project data, and the application of that data to future project estimations. Collection of accurate data is both time consuming and tedious (how many time units do you assign to project X on your time tracking program, if you even submit “timecards”?), even with good tools. For any middle- to large-size company, the amount of data can be overwhelming.

But the main reason estimates still fail is that technical managers continue to employ the man-month (defined as one person’s effort over a 30-day span) as a project unit of measure, which is still used only because it is an historical artifact. The measurement is misused because people still do not understand the measurement and its implications. Some management types, when faced with a slipping schedule, look at the project time line and either do not understand, or just plain ignore, the critical path. They fool themselves into believing that a task that is allotted multiple man-months can be completed in half the time by doubling the resources. Brooks wrote that adding resources not only failed to expedite the project, the strategy often caused added delays. His words from 1975 ring true today.

Can we talk?
Communication, a minor theme in many of the essays, is one area that has improved immensely since the essays were written.

Where three decades ago paper memos, meetings, and yellow “While You Were Out” notes were the available communication devices, today we have e-mail, voice mail, pagers, and cell phones to keep team members in touch. If anything, there is a new issue to add to the issue list: information glut.

On my dream team, there would be…
“The Surgical Team” essay discusses a project team’s make-up. It is a lesson that has, for the most part, been well heeded. Although its language may be a bit dated, the main themes (the team concept and assigned roles) are better used today than they were 30 years ago.

The industry scores high in the areas of the lead programmer (architect, or designer), administrator (project or product manager), toolsmith (the team member that enjoys writing internal tool programs), and the language lawyer (the team member that knows the programming language inside out). Where I have seen us fall a bit short is in the area of editors and technical writers, support staff and Quality Assurance testers.

Hand me that socket wrench
The essay “Sharp Tools” discusses the need for improved tools to do our jobs. It addresses compilers, assemblers, libraries, programming tools, documentation, and high-level languages.

The industry has excelled in giving us improved tools in the past 30 years. In 1972, most computer projects had to write their own compilers or interpreters and, in some cases, languages. Today, we buy them off the shelf. Most have matured to the point of blind trust (ever think twice about calling fprint or using grep?).

Documentation (my own current area of interest) is an industry unto itself. Still slightly lacking, it has matured greatly from the old-line editors to today’s powerful tools (FrameMaker, AuthorIt, RoboHelp, etc.). The latest “new thing” in documentation is single sourcing, a difficult concept to implement, and still in its infancy in many ways. But it holds as much promise for writers as DLLs did for programmers years ago.

I can write that routine in one line of code
“Ten Pounds in a Five-Pound Sack” is one of the essays that, if one of its minor points weren’t still so true, it would make me cry.

It is about budgeting and managing memory and storage space—two areas that, today, are far from a programmer’s mind when writing code. The hows and whys of memory storage management are discussed, and the designer/architect and project manager are asked to be guardians of the resource’s integrity.

With both resources cheap and readily available today, making the effort to conserve them is a nonissue to some. Many times, I have seen a programmer chuckle during a code review when someone has challenged the verbosity of the subject code.

And now we have “bloatware” coming at us from all directions. Internet downloads can be painfully slow at times, especially for those who don’t have the latest and speediest equipment and access.

Although the essay’s examples and language may be archaic, the theme is universal, and speaks volumes to us about what are “good” programming and designing practices, and what are not.

Take a second look
Even though The Mythical Man-Month essays are more than 25 years old, they are as relevant today as they were when first written. So, go dust off your copy, or read these excerpts and order a copy online. You might be surprised at how current some of the ideas are.