![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Brooks's Law
Nov. 5th, 2022 11:04 amBook Review: The Mythical Man-Month - Essays on Software Engineering (Anniversary Edition), by Frederick P Brooks Jr
This classic came up a few months ago at work; whilst I'd heard of it and read the No Silver Bullet paper as an MSc student, I had never read the whole book. I decided it was worth a go, to see how relevant it still was. (The author was a manager working on IBM System/360 and OS/360 in the 1960s/70s, the book originally published in 1975 with this update twenty years later.)
The first thing I noticed was the quite chatty and cheery style; it has the air of fond reminiscence of something achieved, despite difficulties. It also has an air of pragmatism, pointing out the need to work within the reality of any situation. There are some aspects of the book that are laughably dated - who below C-level has secretaries now? - and aspects that are dated in other ways - Brooks exclusively uses male pronouns to refer even to abstract colleagues. (Though to be honest, it grates in more modern books when one feels the author pointedly using female pronouns. I'm sure it's not easy to word everything in a neutral style, but perhaps we should try harder.)
But by and large, and lifting from Brooks's terminology in the No Silver Bullet chapter, the dating of technology is "accidental" rather than "essential" to any of his arguments. On the title essay, the principle is that the conventional relationship between effort (man-months) and delivery timescales does not apply to IT projects: there are practical limits that mean you can't deliver something more quickly by adding more human resources to it, in a way that might apply in other industries. The interrelationships between tasks just generates dependencies and non-linearity. Other essays in the book give thoughts and advice on how to better run such a project.
I found the essay on "Surgical Teams" particularly interesting, as it is perhaps the one area where the author's views do not conform to current practice - he argues for a strong hierarchical and command structure, whereas current practice emphasises interchangeability and flattened, empowered teams. However, the corollary of this is that it undoubtedly weakens what Brooks calls "conceptual integrity": in almost all services and systems the absence of a singular "controlling mind" is visible in the inconsistencies and joins between components, or even individual endpoints within a service.
Whilst it's not written in such terms, there is clearly embryonic thinking about agile processes. In one of the update chapters, Brooks reflects on, and has the honesty to disagree with, some of what he had written earlier. The waterfall model comes in for some criticism and he re-evaluates his approach to prototyping with an emergent direction towards incremental delivery. This perhaps is an "essential" change, the ability to release software more or less on-demand.
But fundamentally, Brooks's Law still applies: Adding more software developers to a late-running project makes it run even later.
This classic came up a few months ago at work; whilst I'd heard of it and read the No Silver Bullet paper as an MSc student, I had never read the whole book. I decided it was worth a go, to see how relevant it still was. (The author was a manager working on IBM System/360 and OS/360 in the 1960s/70s, the book originally published in 1975 with this update twenty years later.)
The first thing I noticed was the quite chatty and cheery style; it has the air of fond reminiscence of something achieved, despite difficulties. It also has an air of pragmatism, pointing out the need to work within the reality of any situation. There are some aspects of the book that are laughably dated - who below C-level has secretaries now? - and aspects that are dated in other ways - Brooks exclusively uses male pronouns to refer even to abstract colleagues. (Though to be honest, it grates in more modern books when one feels the author pointedly using female pronouns. I'm sure it's not easy to word everything in a neutral style, but perhaps we should try harder.)
But by and large, and lifting from Brooks's terminology in the No Silver Bullet chapter, the dating of technology is "accidental" rather than "essential" to any of his arguments. On the title essay, the principle is that the conventional relationship between effort (man-months) and delivery timescales does not apply to IT projects: there are practical limits that mean you can't deliver something more quickly by adding more human resources to it, in a way that might apply in other industries. The interrelationships between tasks just generates dependencies and non-linearity. Other essays in the book give thoughts and advice on how to better run such a project.
I found the essay on "Surgical Teams" particularly interesting, as it is perhaps the one area where the author's views do not conform to current practice - he argues for a strong hierarchical and command structure, whereas current practice emphasises interchangeability and flattened, empowered teams. However, the corollary of this is that it undoubtedly weakens what Brooks calls "conceptual integrity": in almost all services and systems the absence of a singular "controlling mind" is visible in the inconsistencies and joins between components, or even individual endpoints within a service.
Whilst it's not written in such terms, there is clearly embryonic thinking about agile processes. In one of the update chapters, Brooks reflects on, and has the honesty to disagree with, some of what he had written earlier. The waterfall model comes in for some criticism and he re-evaluates his approach to prototyping with an emergent direction towards incremental delivery. This perhaps is an "essential" change, the ability to release software more or less on-demand.
But fundamentally, Brooks's Law still applies: Adding more software developers to a late-running project makes it run even later.