Book Review: The Mythical Man-Month by Frederic Brooks

When the Mythical Man-Month came out in 1975, it opened a lot of eyes in the world of software engineering. Is computer programming an art or a science? The book gets it title from an initial programming premise that if a programming project required the service of one programmer for a month, that one man-month of effort could be achieved by two programmers in a half a month of calendar time. Frederic Brooks was one of the early authors to debunk this myth with painful stories of project failures. He imparted his wisdom in software project management lessons that we now take for granted like the theory of gravity. We used to joke "Let's get 9 women together and have a baby in a month."

Since it has been over 35 years since I first read The Mythical Man-Month, I consulted the summary using our pilot of the getAbstract service. Some of the Take-Aways from their summary included:

• Conceptual integrity is the most important consideration in software design. A single mind or a few like-minded people should be in charge of complex projects. Design by committee leads to a hodgepodge of a system that pleases no one.

• Organization and clear, complete, standardized documentation are essential to any large-scale programming effort. Some say that programming projects can be done with six or fewer programmers or more than 200 programmers. With a programming few, consistent communication can be done by word of mouth. With a large programming team, everything gets written down because so many people need to know.

• Adding new people to the development process slows progress. This happens because the existing programmers have to slow down to train the newly added programmers. It also raises the amount of communication overhead to keep everyone on the same page.

• Programmers are like architects: Their first version is clean, their second overly complicated, and their third better than the second. Just like practicing golf swings or free throws, people execute better as they repeat a process they have already followed. Project managers should plan to create multiple versions of their products.

• Usually, disasters don't cause project delays.
  Q: How does a software project get to be a year late?
  A: One day at a time.

• Software development will never grow as fast or steadily as hardware capacity. This was stated in 1995. Bill Gates once said "How could you possibly need more than 640K?" Today systems consume gigabytes of memory and operate on terabytes of data.

When I was first programming, my biggest concern was efficiency. CPUs were not what they are today. Picking the wrong algorithm or sloppy programming could really do your program in. Next important was readability. If another programmer could not review and help maintain your code, you really had done a disservice to the organization that paid you to write it. My third most important consideration was symmetry. For every begin, there should be an end. For every open, there should be a close. When I worked at GTE on an Apollo workstation project, we all had a laugh at the code for the IBM mainframe (our nemesis) that had an operation called file_copy_with_print. Really?

Though Brooks wrote his book in 1975, and a lot has changed since then, he did get one thing right - conceptual integrity. Someone has to be the keeper of design elegance. Today at Autodesk we use an Agile development process. Projects have a Business Owner who maintains the integrity of the overall user experience. Projects have a Software Architect who ensures that systems meet functional, performance, and stylistic requirements. Systems are built in two week sprints so projects don't get too far off the rails before corrective actions are taken.

Debunking mythology is alive in the lab.