This is a very shallow summary of the Mythical Man Month, and it leaves out at least one concept that the book is most (in)famous for: the '10 times programmer'.
An excerpt:
> In one of their studies, Sackman, Erikson, and Grant were measuring performances of a group of experienced programmers. Within just this
group the ratios between best and worst performances averaged
about 10:1 on productivity measurements and an amazing 5:1 on
program speed and space measurements! In short the $20,000/year
programmer may well be 10 times as productive as the
$10,000/year one.
Brooks did mention some other really useful concepts that are still very valid today: 'No silver bullet' and 'The second-system effect'. These should have been mentioned as well.
I agree. Mythical Man Month is a book to read. It's clear, interesting, and has better writing than summaries.
Many classics like this are so good because the author is among the first to observe new phenomena. They can write down what they have learned without cultural narratives that distort reality.
The hardest lesson in the book is the chapter 11 "Plan to Throw One Away". I have never seen this not to be the case in large systems. You must design the system to be rewritten. Accepting this is still a taboo.
> 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, smarting but smarter, and build a
redesigned version in which these problems are solved. The discard and redesign may be done in one lump, or it may be done
piece-by-piece. But all large-system experience shows that it will
be done.2 Where a new system concept or new technology is used,
one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time.
>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 custom-
ers buys time, but it does so only at the cost of agony for the user,
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.
> 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.
It's not that clear! Perhaps you will only learn the lessons of why the throwaway version sucked by delivering it to customers. And it might buy you a lot of time, perhaps multiples of the initial time to get the pilot working.
Brooks has a point, but it may have been more true in the days of shrink-wrap software than SaaS and continuous updates.
I'd argue that it's more important to build an institution capable of retaining knowledge. The worst results are when the pilot system sucks and a whole new team is brought in to build the second version. They'll inevitably start building their pilot version, which sucks, and repeat until management gets sick of funding new teams for the same project (I feel this happens disproportionately in banking for some reason). Instead, you need to keep substantially the same team around to fix their mistakes in the second version.
>The hardest lesson in the book is the chapter 11 "Plan to Throw One Away"
On the contrary, aren't factors like Microservices and all the constant prototyping at large companies encompass this? I feel in some ways they may have embraced the principle too much, to the point where prod doesn't have a properly stable solution to support while they are re-writing an experimetal "improvement".
Well, this was a bigger issue when this book was written and software was typically developed on disks that couldn't be updated after sale. In the SaaS world, I think deploying your MVP and then rewriting/improving while you have customers running into real world feedback and pain points, and also generating revenue to validate market demand, is strictly preferable to taking an extra cycle and not be in market.
I understand the drive to consume book summaries instead of books themselves. There are way too many books, life moves fast, we need results yesterday.
I also think that if we summarized all the great books ever written and boiled them down to one phrase, it would be "read more books".
Has anyone else started feeling the following? In the last year or so, reading a banal, superficial, and platitudinous summary of something has, for me, become inflected with this feeling that it was written by GPT.
In the case of this article, there are little details that suggest it was written by a person, like randomly choosing to abbreviate the book to T-MMM. But still, it's started happening for me that an article can feel "GPT-ish".
And by 20K/yr programmer he likely means more experienced. Programmers tend to interpret this 10X as rockstar extremely prolific code programmer. In my experience the 10X programmer doesn't do things that impede the group or has enough experience to reduce the solution space to something manageable. Writing code is only part of the equation. Getting to a solution that works well cuts the time and lays the ground work for iterations and improvements. People the spew code that generally works are not as helpful.
I sympathize with your sentiment, but I don't think Go has anything to do with this.
The disregard for the fact that some engineers are more productive than others originates from companies' processes and planning. Projects are usually estimated without considering who will be working on the project and individuals are compressed to person-weeks. I have experienced it myself and read texts describing this issue in the same terms[1].
It doesn't really help that Go was designed in such a company, but saying that it was designed to mitigate this disparity is saying that the best predictor of an engineer's productivity is the number of LOC cranked out. I don't think that is the case, neither in principle nor in Google particularly.
Much better predictors of productivity are effective communication and conceptual integrity of the design, as the linked article points out. It doesn't really help that you use brilliant language if, 6 months in, you've realized you're building the wrong thing, or you build it in the wrong way.
In the end, Go is indeed effective at making engineers avoid arcane and difficult code, but doing the "difficult" stuff that's not available in Go is definitely not how the most productive engineers are productive.
IMO, someone making code that abuses special features to the point it is difficult for other members (including future members) of the team to read is the definition of a negative-X programmer. Unless they're working solo, of course.
Also, like wavesbelow mentioned in his great comment, the "10x" doesn't come from coding prowess alone: it starts long before that, with the process and planning.
I am surprised that there's less mention of Brook's proposed team organization, a team of 10 led by a surgeon. The team is supposed to work on a single project. Every org I have seen has much smaller teams with much more individual responsibility and attendant coordination problems.
I can see shaving 1-3 people off of Brook's ideal team (we don't need a secretary to type anymore, PM's that organize projects at the behest of a technical leader are effective).
What I have seen over and over is, whoever writes the most code tends to get the most power in an org. Whoever is delivering features quickly gets power. This kind of works, but these coders frequently leave poorly thought out architecture that is hard to extend.
That’s another book: the Peter Principle, by Laurence J. Peter. It’s also in my “books you need to read if you’re going to work on a development team” list.
Not only that, but there is a threshold where delivering features more quickly may indicate poorly thought-out, hard-to-maintain code. So you really need to have an experienced developer as a supervisor to assess quality of implementation, and not just look at the quantity of features delivered.
While Brooks' book is nominally about software processes, in my career of over 40 years, I found it to be applicable to just about every engineering discipline to which I played a part. I read this book back in the 70's and then every 10 years or so and I never failed to learn something new from it. I just wish the managers and companies I worked for would have applied these lessons.
I'm a bit of a broken record on the idea, but I'm fairly convinced that much of what we think is unique to software is not that unique. Coordinating work with people is hard, pretty much period.
I think we forget how much software engineering should be influenced by other engineering disciplines, rather than the other way around – I think there are plenty of cautionary tales of "move fast, break things" physical things startups.
Human organisations, whether governmental, commercial, educational, religious, military, charitable, social, or any other principle focus, tend to have and exhibit strongly similar patterns.
There is of course also domain-specific knowledge, but even much of that almost always proves more general on closer examination, with much of the distinction being of labeling and language rather than behaviour and phenomena.
Yup, this book is always in the must read list for software developers but I've barely met any product/project/program managers that have even heard of it. They're often the people that would gain the most insight from the topics in the book.
The Mythical Man Month is great. What makes it great, is that it circles around how important everything but code is, in any professional software development progression.
I would argue that it should be the bible for every manager that are managing engineers. They should study it thoroughly and all the literature it touches and mentions.
The best book I have read on software development by far.
It's always a surprise to know how far back good ideas actually go. Brooks figured out all this stuff in the 70s, pretty much as soon as it was possible for someone to have done this type of work and written a book about it.
Reminds me of Adam Smith's writings about the nascent factory economy, and perhaps ancient philosophers as well.
The article also points out that programming, even more than other professions, suffers from a lack of available "old people in the trenches" who can pass on these ideas to newcomers. This is because:
- the field has been growing so much that at any point in time the majority of devs will be relatively new. A field that doubles every three years will never have more than 50% of people with more than 3 years of experience, obviously.
- I have no numbers to back this up, but intuitively it feels like more devs "drop out" of software development than in other professions. Many become managers, others take up various non-development projects or retire altogether. This makes it so that even less senior people are available.
I think a big part of the "old people in the trenches" problem is that tech has historically had an "up or out" mentality. It seems like most of the older engineers I know either get pushed out or end up as principal engineers where they aren't routinely interacting with the younger people. I've encountered a few people who have managed to avoid this, but it's rare.
It doesn't help that our industry has been incredibly fast-moving compared to most industries, and our interview process is geared toward either being a fresh grad who's taken and algos class recently or knowing all the latest frameworks. Not a lot of places are interviewing on the sorts of experience you gain over a couple of decades in the industry -- which, to be fair, is often more intangible and harder to interview on.
Yeah I also get this feeling that a lot of junior devs decide they don't really want to do it anymore. It's hard to get numbers on it because they will still have a related job title.
I think the problem is that Computer Engineering is still not an engrained concept in universities. Sure, there are courses where some concepts are taught, but it's difficult if not impossible to tailor your degree towards being a real engineer.
I'd call them eventualities more than ideas. Do X thing in Y way and certain things are going to result every time. Somebody finally puts that in a book. But most people are either ignorant of it, forget it, or ignore it.
We can't just assume the people we hire will avoid the eventualities. This is why we need process, to force people into working in ways that avoid as many of the problems as possible. But then the problem becomes getting people to do the process correctly.
I believe the one thing that could transform the industry most significantly is better management. Most managers and team leads I have worked with, even if they've heard of these books, do not act in ways to prevent their problems. They fall into a rut, because they are not following a process.
It gets even worse when they claim to be following a process but aren't. There's loads of business improvement processes out there, but most are paid lip service. Then people get jaded at the process rather than the person or leadership team who clearly wasn't doing it.
Since you bring up Smith, one of the absolutely glaring oversights of Wealth of Nations is that it utterly fails to grasp or note the role steam power would play in the next century of increasing automation, factory-system development, and transportation within England and the economies of Europe and North America especially.
This is all the more gobstopping an oversight when you realise that Smith not only know of James Watt and his steam engine, but was personally acquainted with Watt, personally arranged for him to have a position at the University of Glasgow, and that that was specifically to work and improve the University's own steam engine. Watt remained at that post for a decade or more if memory serves, much of that prior to the publication of Wealth in 1776.
The concept of "conceptual integrity" is one of the most useful things I've ever learned. The tension between conceptual integrity and things like group-based communication and requirements-gathering (what one might call "representativeness") seems to me to be a foundational issue not just in software development but in human civilization as a whole.
Readit News
> In one of their studies, Sackman, Erikson, and Grant were measuring performances of a group of experienced programmers. Within just this group the ratios between best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements! In short the $20,000/year programmer may well be 10 times as productive as the $10,000/year one.
Brooks did mention some other really useful concepts that are still very valid today: 'No silver bullet' and 'The second-system effect'. These should have been mentioned as well.
Many classics like this are so good because the author is among the first to observe new phenomena. They can write down what they have learned without cultural narratives that distort reality.
The hardest lesson in the book is the chapter 11 "Plan to Throw One Away". I have never seen this not to be the case in large systems. You must design the system to be rewritten. Accepting this is still a taboo.
> 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, smarting but smarter, and build a redesigned version in which these problems are solved. The discard and redesign may be done in one lump, or it may be done piece-by-piece. But all large-system experience shows that it will be done.2 Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time.
>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 custom- ers buys time, but it does so only at the cost of agony for the user, 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.
>Hence plan to throw one away; you will, anyhow.
It's not that clear! Perhaps you will only learn the lessons of why the throwaway version sucked by delivering it to customers. And it might buy you a lot of time, perhaps multiples of the initial time to get the pilot working.
Brooks has a point, but it may have been more true in the days of shrink-wrap software than SaaS and continuous updates.
I'd argue that it's more important to build an institution capable of retaining knowledge. The worst results are when the pilot system sucks and a whole new team is brought in to build the second version. They'll inevitably start building their pilot version, which sucks, and repeat until management gets sick of funding new teams for the same project (I feel this happens disproportionately in banking for some reason). Instead, you need to keep substantially the same team around to fix their mistakes in the second version.
On the contrary, aren't factors like Microservices and all the constant prototyping at large companies encompass this? I feel in some ways they may have embraced the principle too much, to the point where prod doesn't have a properly stable solution to support while they are re-writing an experimetal "improvement".
I also think that if we summarized all the great books ever written and boiled them down to one phrase, it would be "read more books".
In the case of this article, there are little details that suggest it was written by a person, like randomly choosing to abbreviate the book to T-MMM. But still, it's started happening for me that an article can feel "GPT-ish".
The disregard for the fact that some engineers are more productive than others originates from companies' processes and planning. Projects are usually estimated without considering who will be working on the project and individuals are compressed to person-weeks. I have experienced it myself and read texts describing this issue in the same terms[1].
It doesn't really help that Go was designed in such a company, but saying that it was designed to mitigate this disparity is saying that the best predictor of an engineer's productivity is the number of LOC cranked out. I don't think that is the case, neither in principle nor in Google particularly.
Much better predictors of productivity are effective communication and conceptual integrity of the design, as the linked article points out. It doesn't really help that you use brilliant language if, 6 months in, you've realized you're building the wrong thing, or you build it in the wrong way.
1. https://danluu.com/people-matter
IMO, someone making code that abuses special features to the point it is difficult for other members (including future members) of the team to read is the definition of a negative-X programmer. Unless they're working solo, of course.
Also, like wavesbelow mentioned in his great comment, the "10x" doesn't come from coding prowess alone: it starts long before that, with the process and planning.
Go was designed to maximise the number of 'any developers' that could join a project, i.e. 1x developers.
I can see shaving 1-3 people off of Brook's ideal team (we don't need a secretary to type anymore, PM's that organize projects at the behest of a technical leader are effective).
What I have seen over and over is, whoever writes the most code tends to get the most power in an org. Whoever is delivering features quickly gets power. This kind of works, but these coders frequently leave poorly thought out architecture that is hard to extend.
Human organisations, whether governmental, commercial, educational, religious, military, charitable, social, or any other principle focus, tend to have and exhibit strongly similar patterns.
There is of course also domain-specific knowledge, but even much of that almost always proves more general on closer examination, with much of the distinction being of labeling and language rather than behaviour and phenomena.
I would argue that it should be the bible for every manager that are managing engineers. They should study it thoroughly and all the literature it touches and mentions.
The best book I have read on software development by far.
Reminds me of Adam Smith's writings about the nascent factory economy, and perhaps ancient philosophers as well.
- the field has been growing so much that at any point in time the majority of devs will be relatively new. A field that doubles every three years will never have more than 50% of people with more than 3 years of experience, obviously.
- I have no numbers to back this up, but intuitively it feels like more devs "drop out" of software development than in other professions. Many become managers, others take up various non-development projects or retire altogether. This makes it so that even less senior people are available.
It doesn't help that our industry has been incredibly fast-moving compared to most industries, and our interview process is geared toward either being a fresh grad who's taken and algos class recently or knowing all the latest frameworks. Not a lot of places are interviewing on the sorts of experience you gain over a couple of decades in the industry -- which, to be fair, is often more intangible and harder to interview on.
We can't just assume the people we hire will avoid the eventualities. This is why we need process, to force people into working in ways that avoid as many of the problems as possible. But then the problem becomes getting people to do the process correctly.
I believe the one thing that could transform the industry most significantly is better management. Most managers and team leads I have worked with, even if they've heard of these books, do not act in ways to prevent their problems. They fall into a rut, because they are not following a process.
It gets even worse when they claim to be following a process but aren't. There's loads of business improvement processes out there, but most are paid lip service. Then people get jaded at the process rather than the person or leadership team who clearly wasn't doing it.
This is all the more gobstopping an oversight when you realise that Smith not only know of James Watt and his steam engine, but was personally acquainted with Watt, personally arranged for him to have a position at the University of Glasgow, and that that was specifically to work and improve the University's own steam engine. Watt remained at that post for a decade or more if memory serves, much of that prior to the publication of Wealth in 1776.
A group of 8 persons provides the same amount of work as 4 individuals.
Ringelmann effect - https://en.wikipedia.org/wiki/Ringelmann_effect
Social loafing - https://en.wikipedia.org/wiki/Social_loafing
Doesn't it increase by n^2? as per the picture with the graphs?