This post is part of a series of posts with my personal notes about the chapters in the book “The mythical man-month” by Frederick P. Brooks. I write these posts as I read through the book, and take notes on the concepts I find more relevant. I do, however, advise reading the book to get the full benefit out of it.
This chapter was added to the 20-year anniversary edition of 1995 and is a transcript of a paper Brooks wrote back in 1986 titled “No Silver Bullet – Essence and Accident in Software Engineering“, which won him the Turing award, often described as the “highest distinction in computer science” and “Nobel Prize of Computing”.
In it, Brooks addresses the essential tasks of building software and suggests:
- Exploiting the mass market to avoid constructing what can be bought;
- Using rapid prototyping as part of a planned iteration in establishing software requirements;
- Growing software organically, adding more and more function to systems as they are run, used, and tested;
- Identifying and developing the great conceptual designers of the rising generation.
I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.
The mythical man-month, pg 182
Brooks talks about Essential Complexity, the complexity inherent to the domain and the problem at hand, and about Accidental Complexity, the complexity derived from representing the problem in code, due to the misunderstanding of the problem, the domain, limitations of the programming language, bugs, etc.
- Essential complexity: The mental crafting of the conceptual construct;
- Accidental complexity: Its implementation process.
Solving the problems derived from accidental complexity is something that can be achieved through tools and language constructs that can help developers better express the domain, prevent technical errors and speed up development. This is easier to optimize and improve upon than the difficulties arising from essential complexity.
Already back then, Brooks understood that the most difficult part of software development is understanding the domain, the problem to solve, and how to conceptually fit it with the existing application. It seems to me that Brooks was already talking about the problem, and some of the solutions, that Domain Driven Design tries to address.
More than that:
Therefore the most important function that software builders do for their clients is the iterative extraction and refinement of the product requirements.
The mythical man-month, pg 199
and
Therefore one of the most promising of the current technological efforts, and one which attacks the essence, not the accidents, of the software problem, is the development of approaches and tools for rapid prototyping of systems as part of the iterative specification of requirements.
The mythical man-month, pg 200
Which are ideas present in today’s agile and lean methodologies.
Since understanding the domain is the most difficult part in software development, the people that can understand, explain and design the domain are some of the, if not the, most important people in a team.
Companies must understand the importance of great designers, and very scarce they are. They should be rewarded similarly to great managers, not only in salary but also in office size, furnishings, personal technical equipment, travel funds, staff support, etc.
How to grow great designers? Brooks makes some suggestions:
- Systematically identify top designers as early as possible. The best are often not the most experienced;
- Assign a career mentor to be responsible for the development of the prospect, and keep a careful career file;
- Devise and maintain a career development plan for each prospect, including carefully selected apprenticeships with top designers, episodes of advanced formal education, and short courses, all interspersed with solo design and technical leadership assignments;
- Provide opportunities for growing designers to interact with and stimulate each other.
@hgraca 