The Mythical Man-Month at 50 (https://en.wikipedia.org/wiki/The_Mythical_Man-Month)
Perhaps the first introspective book about software production; at the very least, the first truly widely read (i.e., “popular”) book on the subject. I remember it being a fairly easy read, and insightful. I read this in the early 2000s after finding it on a colleague’s bookshelf in his office, when it was “only” 30 years old. I won’t pretend to have committed it to memory – I considered it a pensive self-reflection with ponderous suggestions about what might have been different working on OS/360 in hindsight with perfect resultant knowledge of the actions taken.
In all honesty, its biggest impact on me was pointing out Melvin Conway’s “Law” – design organizations tend to make designs that are isomorphs of their own communication (i.e., hierarchical) structure, emphasizing organizational flexibility in order to maintain design flexibility. Conway’s “law” is a singular thesis and a much quicker read. (https://www.melconway.com/Home/Conways_Law.html).
The subtitle includes the word “essays”, so it is not intended to be an all-encompassing thesis, but rather a starting point for further understanding of just what the world of software production entailed – amongst a variety of subjects related to developing OS/360 — a conceptual progenitor of all modern operating systems. (https://en.wikipedia.org/wiki/OS/360_and_successors)
The banner “mythical man-month” implies that the outputs of software production are not directly related to the number of person hours assigned. Brooks specifically calls out “late” projects and the addition of (presumably) semi-fungible developers — noting that more developers means onboarding them (drawing away from other work) and more communication tasks to keep them working in concordance with the rest of the team.
I consider the focus on communication, documentation and organizational responsibilities the strongest points to take away from the book as a whole, and while there’s more in the book than just communication – it and documentation are recurrent themes offered as ways to mitigate the frictions and problems he experienced. I found the observations about developer motivations and system complexity worked better as warnings against trying to find simple answers (or factors) when estimating projects than they do as guidelines on how to estimate better. His late (1995) addition to the tome “No Silver Bullet” shores up that point.
IBM’s management structure and the place of OS/360 in IBM’s product offering act as implicit assumptions in the book, and most of his fiddling with who should do what is a result of the assumption that someone or something else was above all those roles and had accountability for the budget – often he calls this simply “management”. The idea that there could be a technology manager – being a technologist first and a manager first – doesn’t appear quite in the cards.
Though I can’t fault him for failing to offer what I consider the “revolutionary” idea of giving software architects control of headcount and budget, they will be able to optimize their teams better — even if they have to delegate some of those tasks to administrative and logistical associates, as long as the architect is ultimately responsible for everything that is built and by whom, down to the detail and the dollar. An architect optimizing a design, must also optimize the team — as the team is the human action instrument through which a design is refined and realized. Since software architects haven’t trained themselves to be accountable for headcount and budget (the market hasn’t demanded it because “management” handles those things), the cycle of careers in which architects are not responsible for the measurable utility of their software organization activity and output in dollars for profitability or cost continues.
Other neat idea presented (and now fairly common in software development when budgeted for) include:
- the “pilot system” (assuming you have R&D budget to handle that, or can R&D with iterative client projects)
- “good” code discipline and data-modeling practices being important
- efforts beyond “coding”, such as testing and documenting
- the second-system effect (mostly a warning about stress-induced “lessons” polluting the next system)
- a rudimentary DevOps valuation – maker of tools for the team
- (out-of-band) bugs/debugging processes: now mitigated through common practices of tracking systems
I remember it as a decent read, if you get the chance, read it at least once, and not just summaries of it, nor critiques of it.
Pursuit of Value 