The Mythical Man-Month - 32 Years Old And Still Relevant

"The Mythical Man-Month: Essays on Software Engineering" is a book written by Fred Brooks back in 1975, based on his experiences managing IBM's OS/360. It's still a classic book, and despite how long ago it was written, much of it remains relevant. People sadly still fail in the same ways today.

The Mythical Man-Month

The idea that adding people to a late project in order to get it done actually makes the project later should be permanently ingrained in people by now. I bet almost everyone is familiar with recent projects (especially in IT departments) where some manager or PM attempts to fix a late project with a few more people. The whole concept that there remains X extra units of work that can be completed by adding Y people seems so seductive. As true as in the book, adding people (or for that matter starting out with too many people) makes the communication harder, and eventually most of the project time is soaked up by overhead.

I remember being in a meeting with a new client about a modest project when EDS showed up and promised they could have 100 people on the job tomorrow. If 10 people could do the project, then 100 people must be better! The federal government always falls for this one.

Progress Tracking

Although people like to measure progress in different ways (I remember at Lotus seeing dozens of huge charts with all sorts of metrics posted everywhere, all pointless, as an encouragement to the teams) the real point is to have many smaller real milestones. I've always been a proponent of small iterations and making progress highly visible; it's easy to say "it's almost done" when no one can see anything. If there is a new version every week that actually does something you can't hide.

Conceptual Integrity

Yet another great idea - that a system needs to be designed as a whole to meet the user's needs and not just be a collection of "features" or "requirements". Determining what is actually necessary often falls to the needs of management, politics, or ego (and commercially to marketing) and the software winds up bloated, ugly, unusable and often "completed" by the mythical month-men.

The Manual

Documentation. What a concept! Often project documentation is written to meet the requirements of management, often to some broken methodology (like the Waterfall, SDLC), instead of the people actually writing the system. I've always wanted to work somewhere where every scrap of discussion, email, IM, request, comment and of course bugs were all stored in the same system and managed by someone for easy examination and searching. In many projects I've seen managers and customers wander around and "ask" for stuff; even email would be an improvement.

The Pilot System

If you are writing your 12th accounting package, then what it takes to develop it is pretty well known. The problem comes if you are developing something that has never been done or before, or at least new for you and your team. It's impossible to estimate such a project; you have to write it once as a pilot or prototype in order to discover the pain points, the difficult algorithms, or to even understand how complicated it will be. It always amuses me for managers to ask for estimates on an unknown project. It's even funnier (or sadder) when they give a date it must be shipping by.

Formal Documents

Like the manual, it is good to have a small set of documents stating what is to be done, basically a roadmap for the benefit of the customer and a starting point for the developer. It has to be constantly updated as new information appears (you are iterating, right?) or it becomes a useless historical oddity. Even better, this information should be versioned right along with every other project artifact. That way you can tell how the roadmap changed over time. It doesn't have to be fancy (DOORS).

Project Estimation

Nothing irritates developers more than having to give estimates, especially for new projects with unknown requirements. Usually they are worse than useless, since in IT a vague estimate often becomes a hard ship date and promise to upper management and the customer, and ends in more mythical monkey business at the end. Often these estimates are based on the assumption that the developers actually have 100% of their time devoted to work; the reality is that the larger the team (and often the larger the management and customer teams are) the smaller % of time is actually useful.

People used to laugh about my estimates and always multiplied by 3. Eventually I learned and began to refuse to estimate at all. It's done when it's done.

Communication

I once worked for a consulting firm that was called in to "rescue" a failed project; apparently their managers had been so paranoid that each developer (30 of them) was forced to work in a vacuum without seeing other peoples work or source code. The code was unbelievably worthless and the only rescue was a rewrite. The company went under soon after.

People have to be able to communicate while working on the project; these days there is no excuse with email, phones, conferencing and IM. Yet when I worked on Aldus Persuasion, my team and the primary author worked together using nothing but phones and Fedex.

Communication isn't just holding meetings and visiting cubes; that's why I still wish for the project artifact database I mentioned above; if information is easily searchable and readable by everyone, then communication can often happen without contact, leaving the face to face meetings to be held far less often. More time to work.

The Surgical Team

Some system have crucial components that really need to be written by the best programmers you have; the assumption that if a system is documented well enough that any monkey can write the code is yet another Mythical.

Code Freeze and System Versioning

Versioning is such a good idea that even today people refuse it. A few years ago I did a contract at a place where the manager argued for 3 months that a version control system was unnecessary and took too much time. Especially in an iterative process, and even more so with multiple parallel developments, you can't live without the best possible versioning system.

Another job I had used a version control system that took hours to tag a version (every file was updated) so branching and tagging were rarely used. Once we switched to Subversion all sorts of improvements happens to the process. With good branching and tagging (and a process for how to use it) you can actually freeze code before every iterative release without slowing down the overall development.

Specialized Tools

No IT shop wants to dedicate people to tools; management thinks of it as a waste of developers. Yet having specialized tools for builds, utilities, frameworks and the like and someone to maintain them fulltime can make development of the real application a lot easier for everyone else. Sadly I've rarely ever seen such a person; usually developers try to squeeze time to build a few things themselves and they are often unsupported and unmaintained. In many places QA winds up in the same boat.

Despite all of the improvements in software development over the years, some things never change. People are still often stupid, don't learn and don't want to listen. Even 32 years after this book was written many of its ideas are routinely ignored.

The costs of ignorance are definitely not a myth at all.