The programmer builds from pure thought-stuff: concepts and very flexible representations thereof. ... Because our ideas are faulty, we have bugs; hence our optimism is unjustified.
The Mythical Man-Month: Essays on Software Engineering is a classic book about software engineering and project management. It was published in 1975, but even almost 50 years later, it is still relevant. It is so relevant that I'm unsure what we have been doing for the last few decades. We obviously know solutions for many common problems, but we have chosen to ignore (obviously) good advice and repeat the same mistakes for decades after decades.
The book is grouped around essays. I have found these ideas the most interesting:
The mythical man-month and Brooks's law
"Adding manpower to a late software project makes it later."
Good cooking takes time. If you are made to wait, it is to server you better, and to please you
Menu of restaurant Antoine. New Orleans
Very often, the best thing the project manager can do is to leave the teams to finish the project without any interference. "You can't produce a baby in one month by assigning nine women to the task," nor does it make sense to micro-manage the baby's growth. But many project managers still do.
Brook goes into detail by explaining that a man-month is a hypothetical unit of work that can be done by one developer in one month. The problem is that it does not scale well for work that includes complex tasks like development. With any task that requires communication and coordination between workers and any new worker, the output would actually decrease, at least in the short term.
No Silver Bullet
"There is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity."
All programmers are optimists. Perhaps this modern sorcery especially attracts those who believe in happy endings and fairy godmothers.
"This time it will surely run."
"I just found the last bug."
Incremental development - grow, not build, software.
It takes a lot of effort to accept the existence of insoluble problems. The wish to see a way out, against all odds, even when it is proven that it does not exist, is very, very strong. Turski
As developers, we are often attracted to new shiny technologies, like moths to flames. With our optimism and attitude of "This will change everything," we frequently think only of the benefits but don't see the disadvantages.
No Silver Bullet was not present in the original book. Brooks added it later in the Anniversary Edition; most ideas are from his original paper - No Silver Bullet (1986)
Second-system effect
The second-system effect or second-system syndrome is the tendency of small, elegant, and successful systems to be succeeded by over-engineered, bloated systems due to inflated expectations and overconfidence. (ref)
Why Monolith with SQL when we could have Event Driven Microservice Architecture with CQRS, NoSQL, Kafka, and K8s? Sure, sometimes it makes sense, but more often than not, it's a mistake.
The Surgical Team
These studies revealed large individual differences between high and low performers, often by an Order of magnitude. Sacman, Erikson, and Grant
Within just this group the ratios between best and worst performances averaged about 10:1 on productivity measurements...
Is this the origin of 10x developer?
On the one hand, it fails to approach the ideal of the small sharp team, which by common consensus shouldn't exceed 10 people.
Is this the origin of Jeff Bezos the two Pizza Team?
Aristocracy, Democracy and System Design
Conceptual integrity, in turn, dictates that the design must proceed from one mind or from a very small number of agreeing resonant minds.
Aristocracy, Democracy, and System Design is probably one of the most polarized chapters in the book. I do understand that many would compare ideas from this chapter with the anti-pattern "The ivory tower architect." But I'm not really sure it was the author's original idea. I am leaning that the goal of the chapter was to acknowledge that some kind of central vision is necessary for any bigger software project and that it is not a good idea to change it later, especially in cases where you don't have the entire picture, but you're just looking at some part.
I believe that in modern agile environments we often push almost all architectural responsibilities to individual teams, making it very hard to have a high conceptual integrity across the entire application or the platform. Not all decisions need to be centralized, but (in my opinion) many do. It is also necessary to have open communication and to enable every member of the team to be heard, even if the final decision will not be theirs to make.
Plan to Throw One Away
It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something. Franklin D. Roosevelt
In most projects, the first system built is barely usable. It may be too slow, too big, awkward to use, or all three. There is no alternative but to start again, making but smarter and build a redesigned version in which these problems are solved.
The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway or to promise to deliver the throwaway to customers. Seen this way, the answer is much clearer. Delivering that throwaway to customers buys time, but it does so only at the cost of agony for the user, a distraction for the builders while they do the redesign and a bad reputation for the product that the best redesign will find hard to live down
There is nothing in this world constant but inconstancy
The only constancy is the change itself
Developers so often fantasize about complete rewrites. It often has bad connotations, especially with management. But what if rewrites can be a standard practice for new and unknown features?
Make it work (or create a small prototype) -> Learn -> Make it again, but much better.
Late changes, especially in the architecture of the system, are very expensive. But even big changes or complete rewrites are reasonably cheap at the beginning.
Word of Caution: Please make your managers understand the difference between the prototype and a production ready application that is secure, scalable, and easy to work with!
Personal Conclusions
- Are you optimistic or pessimistic about the state and the future of software development?
- Yes!
Even if we are slow to learn some things, we have made significant progress in software engineering for the last 50 years! Brooks's conclusions were about software development and software project management, but most of the problems we still have today are much broader than just programming. Maybe the issues we are facing are more related to the human condition than to software development.
The book is a pleasure to read for any software developer. The book truly captures the emotions and experiences of developers, even if it is so old. Maybe we are not that different than our ancestors, even if we have fancy IDEs
and AI autocompletes.
Author Frederick Phillips Brooks Jr.
Frederick Phillips Brooks Jr. (1931-2022) was a famous American software developer and scientist known for working on IBM System/360.