One thing that often strikes me when sitting in on client interviews is how many candidates lack an historical perspective on software development. In a profession of “perpetual beginners”, where new developers are lucky if they’re exposed to old developers conversant with old ideas, it’s understandable that so many of us think of what are, in fact, old ideas as shiny and new. The relentless churn of reinvention is like the winds that shift the sands, burying the edifices of previous civilisations, and leaving today’s developers under the mistaken impression they built their cities first.
I found it very valuable to look back over the history of software development, surprising myself at how so many key insights and ideas date back decades before I thought they did.
But that’s a lot of reading! So, for those of you who are too busy to do that legwork, I thought it might be useful to present summaries of some of those most influential books and papers in a more easily digestible form. Starting with one of the most seminal: The Mythical Man-Month, by Fred Brooks (published in 1975).
Brooks argues that adding manpower to a late software project makes it later, due to the increased complexity of communication. He emphasizes the importance of having a small, skilled team, clear communication, and the need for planning. Brooks introduces the concept of the “Brooks’ Law” and stresses the importance of conceptual integrity in design. He also discusses the challenges of software estimation, the trade-offs between quality and time, and the value of iteration in software development.
Key Concepts:
Brooks’ Law:
“Adding manpower to a late software project makes it later.”
This counter-intuitive principle is based on several key observations and reasons:
- Ramp-Up Time: New team members require time to become productive. They need to learn about the project, its code base, the tools being used, and the team’s working style. This ramp-up time can significantly slow down the overall progress as existing team members spend time training the newcomers instead of working on the project.
- Communication Overhead: As more people are added to a project, the complexity of communication increases exponentially. Every new team member adds additional communication channels, making coordination and information sharing more complex and time-consuming.
- Division of Labor: There’s a limit to how effectively a task can be partitioned among multiple workers. Some tasks simply cannot be divided because of their sequential nature, and for those that can be divided, the division itself can introduce extra work, such as integration and testing of the different parts. You may have come across Brooks’ famous analogy of expecting 9 women to produce a baby in one month. (And before you say it, it didn’t escape my attention that in the world of The Mythical Man-Month, the men do the work while the women make the babies. Hey, it was the 1970s. You’ve seen Life On Mars, right?)
- Diminishing Returns: After a certain point, the productivity per worker starts to decrease as the team size increases, due to the factors mentioned above. This can lead to a scenario where adding more people actually results in less overall productivity.
Brooks’ Law highlights the importance of careful team and project management in software development. It suggests that throwing more resources at a problem, especially in a time-constrained situation, is not always the best solution and can often exacerbate the problem. Instead, Brooks advocates for better planning, clear communication, and setting realistic timelines to avoid the pitfalls of late projects.
Software Estimation
Brooks highlights the inherent difficulties in accurately estimating the time and resources needed for software projects. He points out that optimistic assumptions, failure to account for all necessary tasks (like integration and testing), and the unpredictable nature of creative work like programming often lead to underestimation. Brooks suggests more realistic approaches to estimation, taking into account the uncertainties and complexities involved.
Quality vs. Time
The book discusses the trade-off between the quality of the software and the time taken to develop it. Brooks argues that rushing to meet deadlines often leads to compromises in software quality. He emphasizes the importance of not sacrificing quality for speed, as poor quality can lead to more significant issues and delays later, like increased maintenance costs and system failures. He advocates for a balanced approach where sufficient time is allocated to ensure high-quality outcomes.
Value of Iteration
Brooks promotes the concept of iterative development, which was a significant shift from the prevailing models of his time. He argues that software should be developed in stages, with each stage building on the previous one. This approach allows for continuous testing, feedback, and refinement, leading to a more robust and well-designed final product. Iterative development helps in identifying and fixing issues early in the process, reducing the overall risk and improving the software’s quality.
Conceptual Integrity in Design
This principle emphasizes the importance of having a coherent and cohesive design approach, ensuring that all components of the software work well together and adhere to a central concept. Achieving conceptual integrity often involves a strong guiding hand, such as a chief architect, to ensure that all aspects of the project align with the overarching design philosophy. This approach leads to software that is easier to understand, use, and maintain, as it avoids the complexity and confusion of mixed or conflicting designs.
Hopefully you can see how The Mythical Man-Month has profoundly influenced modern software development. For sure, some of these ideas have evolved and attitudes have changed over the years. It’s debatable whether a book called “The Mythical Man-Month” would get published in 2023, for example. Also, TMM-M dates from a time when organisations were much more hierarchical and less collaborative.
We tend to recommend much, much faster iteration these days than perhaps Brooks and others of his time imagined. (TBF, our computers are about a million times faster, so the inner loop of build & test is much, much shorter these days.) And I may not agree with Brooks’ take on the need for something like a Chief Architect (there are other, arguably better, ways to keep a team singing from the same hymn sheet). Finally, in 2023, many of us now see estimation as solving the wrong problem, preferring instead to deliver working software more often to make real progress more transparent. When trains leave every 5 minutes, the timetable becomes less important.
But the key concepts are mostly the same. If you follow me on social media, you will have seen me espouse “small, skilled teams rapidly and sustainably evolving working software” and championing a focus on quality – continuous testing – as a means to achieving that.
It’s a book every developer and manager of developers should read. And now you can pretend that you have. It’ll be our little secret 😉
Codemanship's Blog 
> And I may not agree with Brooks’ take on the need for something like a Chief Architect (there are other, arguably better, ways to keep a team singing from the same hymn sheet).
Could you expand on this point? Interested to hear your thoughts on this and how you arrived at them.
I tend to favour much closer collaboration on design. e.g., pair programming, ensemble programming etc to establish a common vision and approach. Also, teams where developers tend to be much more conversant with architectural principles, practices and patterns have a shorthand for communicating ideas, like musicians who know the names of all the chords. So, with junior developers, we might conceptualise architecture at the level of “play this note, and this note, and this note, and this note”, but with more architecture-savvy devs, simply “Play CMaj7”. In the discipline of Continuous Architecture, review and refactoring is going on within the team all the time to meet rapidly evolving design needs. You can usually tell these teams by the architecture-centric commit messages and by the visual models (e.g., domain model) prominently displayed.
I agree that Brooks’ “Chief Architect” pattern did not age well. As I recall, he describes it like a surgical team, where one expert doctor does all the most difficult and critical work, and there is a supporting team of specialists to help them. In software, the support team would be tool builders, testers and such.
What we learned much later (around year 2000 or so) with agile was that it’s far more effective to have a team of peers working collaboratively than to have a few “top-level experts” with a team of supporters. Brooks’ “Chief Architect” pattern seemed to be speculative at the time. He did not say that this was working for him; he speculated that it might be a good way to work. With agile, we’ve been reporting on patterns that we have found to work well in actual practice.
Your point might hold if the job of developers was to play written music, rather than to write the music themselves. And having seen what tends to result when we assume that a single design authority can hold it all together at any appreciable scale, with hundreds of design decisions being made every day, whilst directing from above, I know for sure that it just doesn’t work. Architects don’t have magical powers.
My main take away was:
1) Be prepared to throw one implementation away because you’re going to anyway.
2) Be aware of the second system syndrome. (A.k.a. be prepared to throw two implementations away because you are going to anyway)
I like the idea of widening the view and looking back at history. An even older book I enjoyed reading was “Sunburst and Luminary” by Don Eyles. It gives a lot of insight into the development of the Apollo lunar module software in the 1960s – one of the first embedded systems to be developed, and a very survival-critical one for the astronauts, too. Don was a developer for the on-board software and gives first-hand reports in his book.
Nice read!