The Mythical Man-Month, by Fred Brooks
This book was written by Fred Brooks, who managed the IBM OS/360 project in the 1960s. The OS/360 project was responsible for changing the computer world. Brooks originally wrote this book in 1975, and then revisited his words 20 years later in 1995; in the last 3 chapters, Brooks summarizes how his concepts still apply. Overall, this was a great book that is still relevant today. Much thanks to my co-worker, Jarred, for recommending it. The author provides many recommendations and insights from his time managing the IBM OS/360 project, which was run over-budget and over-time, but ultimately yielded massive success for the company. It’s a drastically different style of book compared to the other books that I’ve been reading recently. The book is divided into 19 short essays, and each essay is a short technical paper. My goal was to read each essay and then comment on it.
(1) The Tar Pit
Programming is both fun and woeful. It’s enjoyable because we get to create. We get to make things. We get to solve puzzles. And, we are always learning. But it’s also frustrating. One mis-character can cause hours of debugging and headache. We are dependent on other people to develop reliable programs. De-bugging is often a nightmare. Often, a program becomes obsolete before we are even able to finish it. Oh, that’s discouraging, but it is just a consequence of rapidly advancing technologies. Because of the woes of programming, the software development field is like a tar pit, where many people thrash, flounder, and often drown.
(2) The Mythical Man-Month
The big idea of this chapter, and the whole book, is that adding more men to the project does not necessarily reduce the project timeline. In fact, adding more men often extends the timeline, and costs more money, and creates a buggier project, which is exactly the opposite of the original intention. The maximum number of men on a project is dictated by the number of independent subtasks. As more men are added to a project, things like scheduling, communication, and training take time. This is time that is otherwise not needed on a smaller team
(3) The Surgical Team
All managers would prefer a small, sharp team as opposed to a large, mediocre team. This chapter suggests a structure for a roughly 10 person team. The team is constructed around a single “surgeon,” who is the one highly skilled person with intimate knowledge of the project. The other supporting roles provide testing support, administrative support, scheduling support, and general advice. However, the documentation, the conceptual integrity, and the actual code changes are all implemented by the surgeon. The surgeon determines the project direction and is ultimately responsible.
(4) Aristocracy and Democracy
For the conceptual integrity of a product, it is important to have a uniform vision that was established from just one or two minds. This will ensure that everybody is working towards the same goal. Within the bounds set by the Aristocrat, the developers have the freedom to implement the vision however they want. This idea seems consistent with other ideas that I’ve heard. We, as people, like the idea of having more options and infinite possibilities. But we operate much more efficiently when our design space, or our decision space, is bounded. That’s what the Aristocrat does; he bounds the play/decision space for all of the developers on his team. Just like living as a Christian, I am bounded by God’s rules, but within God’s bounds I actually experience greater freedom.
(5) The Second-System Effect
It is tempting to add many bells and whistles and ornaments into the final product. During an architect’s first system, he sidelines all of the minor extras and stays focused on the big picture. But during the architect’s second project, he desires to incorporate all of the extras that were sidelined on the first project. This consequently adds bugs, complexity, and cost. Beware of adding software embellishments.
(6) Passing the Word
Documentation is crucial. There should be a user manual, written solely by the architect, that defines how the system operates. There will always be the question about whether the documentation is correct or if the computer is correct. Usually, the computer wins because it is simpler to change the documentation/manual. In addition to a user manual, it is also important to document changes and decisions. These decisions should be passed along to all members of the team. My takeaway for this chapter is clear communication. Communication wins.
(7) Why Did the Tower of Babel Fall?
Because of communication failure. They had adequate resources, time, money, man power, and technology. But with no ability to communicate, the project was a disaster. For software development, everything needs to be documented, including decisions, changes, and memorandums. The goal is to ensure that the relevant information gets to all the people who need it. Brooks talks about tracking all of the changes in a physical book, or on microfiche. Obviously, these recommendations are dated. We can track everything electronically using tools like git. This chapter also discusses the roles of “the producer” and the “technical director.” I really like these ideas. The producer’s role is to establish the team, divide the work, and create the schedule. The technical director is responsible for the specific design, sub-parts, and conceptual integrity. In one mode of operation, the producer is the boss, and the technical director is the right-hand-man. In this situation, the producer and technical director must communicate privately to ensure that they have the same technological philosophies. The producer proclaims the authority of the technical director and provides unproportional support in favor of the technical director. For the most part, I think this is how I operate the NPSS project, and it is neat to hear Brooks articulate the mode that I actually work in. The other operation mode is where the producer and technical director are the same person. This only works for small teams (less than 5 people). I like how Brooks says, “Thinkers are rare; doers are rarer; thinker-doers are the rarest.” The man with both the strong management talent and the strong technical talent is rarely found. Now, that’s unfortunate. But I’ve been discovering for myself that it’s the truth. Talented men are hard to find. No matter how many people populate this earth, only a small portion of them will be talented. And those talented people will be in high demand.
(8) Calling the Shot
The big idea of this chapter is that efficiency decreases with time and effort. For a small software project, a single developer can create an efficient and stable program. But as the program becomes more complex, as the number of lines of code increases , the number of man-hours required to complete the project rises exponentially. This is true with everything; over time, we lose energy and efficiency at doing any task. I can create a small program by myself, and it will be done very efficiently. As soon as I need more people on the team, efficiency decreases.
(9) Ten Pounds in a Five-Pound Sack
There are tradeoffs between size, cost, and time. The larger the project, the more time and space it will cost. It is important to set size constraints on the whole project. It is also important to set size constraints on individual modules within the larger program. Through cleverness and craftsmanship, we can reduce the space required by a given program. This comes in the form of ingenious algorithms. However, it also takes more time to develop these spaces-saving algorithms. Hence there is a trade-off between cost, size, and time. Set size budgets.
(10) The Documentary Hypothesis
Documentation is crucial to a successful project. It is used to clearly define the budget, objectives, constraints, decision, and changes. Documentation encourages clear communication. For the manager, only a few documents are critical to his role, such as the budget, schedule, and objective. The manager’s role is to hear, communicate, teach, exhort, and encourage. There are many mini-documents that are irrelevant to the manager.
(11) Plan to Throw One Away
I love how this chapter ends with a quote by C.S. Lewis. And there are other Biblical quotes scattered throughout this book. The point of this chapter is that things change and we should anticipate the changes. The first program we write is not going to be the perfect product. Plan to discard this initial attempt, because it’s going to happen anyway. This is a really insightful observation! The initial attempt will be poorly implemented, but it is also difficult to trash something that so much effort was used to develop. I have seen this with my own experiences. Brooks also talks about maintenance. He recommends planning for maintenance to consume about 40% of the original development cost. Maintenance is making changes to fix bugs. The problem with fixing bugs is that these fixes also introduce new bugs. More bugs -> more fixes -> more patches -> more entropy. This is why test-driven development is important to ensure that all parts of the program operate as expected.
(12) Sharp Tools
A manager needs to set aside resources for common tools, but also recognize that each developer will need specialized tools: tools for debugging, data visualization, testing, tracking, etc. I like how the author points out computer-based text editors, high-level languages, and interactive programming. At the time of this book, none of these items were common. But the author suggests that they should be. What a great prediction. Today, we only use text editors on the computer; no physical paper is used. High-level languages are making low-level languages almost obsolete. The high-level languages are very efficient, with lots of libraries that allow us to do what we want. They are very comprehensive. The author recommends PL/I as his high-level language of choice. I had never heard this language before today. In the modern world, we use languages such as C++, python, and Java. Also, interactive debugging and programming has advanced tremendously since Brooks’ time. High-level languages, interactive terminals, and text editors are examples of sharp tools.
(13) The Whole and the Parts
How does one build a dependable system that will actually work? That’s the question this chapter attempts to answer. Most of the recommendations are not applicable to today’s software programs. What are some of the general themes that I can extract? Start with a precise definition and clearly define the goal. Avoid adding frills, because software ornaments only introduce more bugs. Avoid GO TO statements. These are not used anymore. Track changes and develop tests. It’s crazy that the author wars able to foresee so many of the elements used ubiquitously in modern programming, such as eliminating GO TO functions, text editors, testing, and high-level languages.
(14) Hatching a Catastrophe
How does a project get to be one year late? By letting the schedule slip day-by-day. One day at a time. To avoid slippage, set a schedule. Set milestones. Make these milestones explicit deliverables. Fuzzy milestones allow use to sidestep deadlines; not good. For my project, I think that we need to do a better job of developing strict schedules and milestones. I think that we do this poorly. I also think that means we need to set consequences if the deadlines are not achieved. And if we all brainstorm the consequences, then we’ll be more likely to adhere to the deadlines. Brooks recommends using a PERT chart. My big question here is how do we make reasonable (not optimistic, not conservative) time estimates?
(15) The Other Face
Another chapter on documentation. This one is about documenting the actual code, including the algorithms and the flow. Brooks says that flow charts are not good for designing programs, because flow charts are only developed after the program is complete. I agree. He also spends effort arguing for documentation within the code itself, as opposed to an external document. Some low-level languages do not permit clean in-code documentation. Therefore, this recommendation applies almost entirely to high-level languages. Today, we have high-level languages and text editors that conveniently collapse and expand loops/functions for easy visualization. There is no excuse, other than laziness, for poor documentation. Write a prose definition at the top of the function/file, and make comments describing rationale and decisions within the code. I really like how Brooks uses comments and arrows to show where loops and functions begin and end. Brooks was leading the way for current software development practices. I like the image of how he documented what I no call expand/collapse functionality.
(16) No Silver Bullet
This is the last chapter in the original 1975 book. There is no silver, magical bullet that will slay all the monsters in our nightmares. Similarly, there is no single silver bullet that will yield an order-of-magnitude improvement in software development in terms of simplicity, productivity, or reliability. Let’s discuss a few commonly proposed silver bullets.
The first point is that software is complex; this makes silver bullets fictitious. We’ve been building on top of the work done by years of people before us. It is not possible to understand all the intricacies of what makes a software program work. I like to think of a cell phone as an example. Incredibly complex. So many minds over so many ears were required to develop the smart phone. Nobody understands every piece of the whole unit; it is too complex. This leads well into the next point, which is that we are constantly building on top of, and relying upon, work completed by other humans. The problem here is that humans are not perfect. We make mistakes. This means that our past works are not perfect. They have flaws that modern designers must work-around. This is opposed to the laws of physics, which were designed by God, and are thus flawless and cannot be broken. Physics was created by Gob, whereas computers were created by man. Man is flawed, and thus computers are flawed.
The first silver-bullet-hopeful mentioned by Brooks is the high-level language. He really likes high-level languages because they reduce complexity, and he predicts that they will be hugely beneficial in the future. They are. Next, he talks about object-oriented programming. Again, he predicts this will have significant contribution in the future. It does. What I don’t understand is, if OOP was emerging during the 1990s, then why are we still worshipping its novelty today? It’s not new. Any modern developer is familiar with the concept of classes.
Brooks also talks about artificial intelligence (AI). First, he raises the point that we need to agree on a definition for AI. I agree. I also find it humorous that we were interested in AI during the 80s and saw it as “the next big thing.” Today, 40 years later, people are still fascinated with AI and think it is the “the next big thing.” As computers have matured, so has our definition of AI. Once we understand how AI works, then it ceases to be AI, and we need a new definition. Oh, I like that. Once we understand AI, it ceases to be AI. Hence, the current definition of AI focuses on machine learning. In many ways, machine learning is a black box. We do not understand what is happening inside. Since we don’t understand, we call it AI. Obviously this AI is intelligent and powerful, because this type of AI has proven that it can beat the best human brain in computer games such as chess and Go. AI that beats the very top of human intelligence is impressive.
The last point in this chapter, which I really like, is that the most important part of a software project is the people. We need to focus on growing great designers. There is an order-of-magnitude difference between an average designer and a great designer. Just like great managers are rare, great designers are rare. Everything that I read and observe agrees with these statements. A small number of people will always have a disproportionately large majority of the resources, whether those resources are money, athleticism, intelligence, or power. In the software world, we need to recognize those talented people early, develop a career plan, give them opportunities for training, education, and mentorship. I also like how he says that these great developers must be rewarded with salary, office size, furnishings, support staff, travel funds, and personal technical equipment. Yes, I agree!
Conclusion
I like how the author concludes this book with his last sentence. Software development will continue to advance, but it will require us to continually apply our common sense, and it will require “a God-given humility to recognize our fallibility and limitations.” Humility! Is the keyword. Egos will get use nowhere. Humility will get us everywhere.
I really enjoyed this book! Despite being 50 years old, the ideas are still relevant. That’s amazing. It demonstrates the insight that Fred Brooks had. Also, it’s fun to apply the ideas presented in this book to my own software project, NPSS. It’s exciting to read about new ideas and think about how they can be applied in my own work. I want to apply some of these concepts and do my job more efficiently. I think it’s a good sign that this gets me excited, and that it’s what I’m reading about in my free time. Work is fun for me. I’m very blessed.
The major themes of this book are:
Conceptual Integrity: Conceptual integrity is needed across the entire product. This is accomplished via one or two talented minds clearly defining the system and leading the project.
Documentation: It is far better to be explicit and wrong than to be vague. Documentation includes deadlines, schedules, user manuals, changes, email communication, code comments, budget, and decisions. Clear communication, documentation, and project success are all linked.
Great Designers: At the core of a successful project are the people. Great people do great things. The tools only help great designers accomplish their goals.