Ask HN: How relevant is The Mythical Man-Month outside the software industry?
Or, what are the equivalent lessons from managing engineering projects, outside the software domain?
Or, what are the equivalent lessons from managing engineering projects, outside the software domain?
I'm a little confused by the question. I don't see it applied within the software industry.
Software teams still measure in man-months. We just call them something else, like "story points". I've never seen any estimate or schedule which included team communications costs.
Second-system effect is still just as common as it ever was. We still fix bugs, and in doing so, create other bugs. Many or most systems lack conceptual integrity. We still hire implementors before the architecture is finalized.
I've seen pilot systems only very rarely. I've never seen an architect produce a manual of specifications. I've never seen a surgical team, or anything even vaguely resembling it. I've never seen tool-maker as a dedicated position, even when my manager agreed it would be useful to the team (on the basis that "nobody would want to take that job" even though I volunteered).
The only piece of TMMM that I've ever seen or heard any team try to apply is "No Silver Bullet", and that only as a catch-phrase used to mean "we're fucked either way so don't try". Nobody quoting Brooks has bothered to read that chapter (or that paper) and find out Brooks's criteria for what would constitute a "silver bullet", or try to make one. I can think of a couple examples of partial attempts, but always by UI/PL researchers, never by software engineers quoting Brooks.
Are you looking for "the book everybody knows they should read but nobody actually does"?
TMMM was, broadly speaking, composed of two kinds of things: 1) specific recommendations on procedures (this part looked pretty dated when I read it in 2004) 2) bad news for management, of the sort they don't want to hear - you need to make one to throw away - you can't throw 9 women at a pregnancy and get it done in a month - there are no silver bullets
By and large, the second kind of thing is useful to know, so that you can recognize that particular kind of management mistake when you see it. It won't help you avoid it, unless you're in management, and even then it may not because your hand may be forced from above. But it is less stressful somehow if you can see the pattern in what's happening. "Aha, they are throwing people at a late project, to make it later. Yes, I recognize that."
So, while parts of it are quite valuable and applicable both within and outside the software industry, the actual impact on management behavior is quite small.
As a Brooks reader, I've idly daydreamed about repackaging it as buzzwordy management advice and making a fortune. The issue is that there may not be a market for good management advice, whether down-to-earth or buzzwordy.
I tried to suggest a surgical team at one job, but it didn't really compute for anyone else besides me. (I would not have been the surgeon.)
If you're reading this comment and haven't read Brooks, consider it - not too much of a time investment for the perspective.
Many of your points are accurately stated.
Story points are different from man-months because they are part of a continuous calibration feedback loop. They really differ pretty fundamentally from man-month style estimates in waterfall software delivery. If you are calibrating your story points, they should naturally include team communication costs if those costs are somewhat stable.
Brooks' core insight has been well-heard though. Everyone I work with in software engineering knows that adding more engineers to a project will not get it delivered faster when it's already in crunch time.
In general, "agile" development differs in a lot of ways from what software development looked like when Fred Brooks was writing. If you are delivering software in small increments, making small adjustments and receiving continuous feedback from users, a lot of his advice maybe is not relevant. Hiring implementers when you are still architecting a MVP version of a feature which you will test with customers then rearchitect as necessary is not as big a problem as hiring them when you are working on the final architecture of a system which will be years in development and deployed in a very expensive once-per-year fashion.
Companies (well-run companies, that is) have surgical teams in spirit, in the sense that the more complex projects are taken on by engineers that have successfully executed the most complex projects in the past, and work with more junior engineers on coding those projects. And there are often development teams with people fulfilling different roles as part of projects. Many companies have teams responsible for development tooling, including pretty much every FAANG and most large startups.
In general, it would be surprising if Brooks had happened to be exactly right in all of his observations writing 40 years ago. In well-run companies, we see a lot of things which Brooks was pointing to were exactly accurate, but we also see that in many ways we've moved past his predictions of the best way to do things. In badly run companies, many are still making the mistakes Brooks talked about, because they are attractive or "obvious" ways of thinking about software development.
> Companies (well-run companies, that is) have surgical teams in spirit, in the sense that the more complex projects are taken on by engineers that have successfully executed the most complex projects in the past, and work with more junior engineers on coding those projects.
That doesn't sound anything like a surgical team to me. It just sounds like you're mixing experience levels to train new people.
As Brooks said (paraphrasing Mills), "instead of each member cutting away on the problem, one does the cutting and the others give him every support that will enhance his effectiveness and productivity." The anesthesiologist and radiographer and nurse aren't just less-experienced surgeons. They're not surgeons at all -- and I hope they're just as skilled at their jobs as the surgeon is.
There is a qualitative difference in results when you have a dedicated person in charge of something.
> In general, it would be surprising if Brooks had happened to be exactly right in all of his observations writing 40 years ago.
Why? Has human nature changed in 40 years? This isn't like reading Plato, where he simply made up things he didn't understand. On the contrary, I would be much more surprised if the nature of team productivity had changed in only 40 years.
> That doesn't sound anything like a surgical team to me. It just sounds like you're mixing experience levels to train new people.
I think I'm more saying that we have moved toward a specialization of labor that supports the software engineer in a different way, even though it hasn't ended up looking like a surgical team. We have product managers who understand the user's needs and organize feedback sessions, we have product designers who are experts of UX design, we have junior engineers that implement components with the oversight of the more senior engineer, etc. It has ended up being more collaborative, and it's not clear to me that it would be better if instead we tried to organize it around a single person who was the overall "surgeon" who did the key aspects of all this work with the others in a supporting position.
In some companies there is a "directly responsible individual" who is in charge, but in others there isn't. Are they acting as a surgeon in that case, or are they doing project management? It depends on the organization. How much ownership that person has and what is the impact on that person of success and failure? It's hard to analyze a different organizational framework as it relates to Brooks.
> Why? Has human nature changed in 40 years? This isn't like reading Plato, where he simply made up things he didn't understand. On the contrary, I would be much more surprised if the nature of team productivity had changed in only 40 years.
Brooks' writing wasn't grounded in fundamental human truths, it was grounded in his observations of software projects that existed in 1975 and related observations of how work was performed in other industries.
My intuition is that if there are Way A through Way Z ways of doing things that are optimized for A through Z different types of organizational problems, Brooks was saying "Way D is the best for software projects." But because we now work on different types of problems (much shorter feedback loops, higher levels of abstraction, users with higher levels of sophistication, greater importance of software ecosystem) maybe Way E (Silicon Valley style agile, lean product management, etc.) is more appropriate. Since Way E has been successful in the market, it at least seems adaptive. Otherwise companies would have a strong incentive to change to Brooks' Way D.
Yes, the practices everyone should follow, because they make sense. The - nobody actually does - part is a whole new discussion.
Question popped in my head while reading this para from the book - "Techniques proven and routine in other engineering disciplines are considered radical innovations in the software engineering" What are such practices? What other practices can the software industry derive from other engineering domains?
This is the best book on software engineering and project management.
1. Need standards for process, coding style, change control, documentation. Must be easy to move people between projects without massive retraining. Implies use only one programming language.
2. Change control is essential.
3. Some projects cannot be completed faster: Nine women will not produce a baby in one month.
4. Forced schedules will impact quality.
5. There is No Silver Bullet. There is implicit difficulty that cannot be changed by tools, process, training.
Just read the book!
I'd also add 1A) when hiring, you must consider the amount of time to train a person and that each additional person adds more work for communication. It explains why adding more people to a project that is already late, will actually make it later
This is probably the best short summary I've seen on The Mythical Man-Month. Kudos! Do you have any other books of a similar vein to recommend?
I am reading the book :)
I just wanted to know, given that someone outside the software engineering has read the book or that someone inside the software engineering, can shed some light on - "the techniques proven and routine in other engineering discipline are considered radical innovations in software engineering".
Remember that the book was written in the 80s, so some things have been adopted since then. One example is version control, which wasn't standard until the mid-2000s. A different example is that most other engineering disciplines require formal diagrams to be created and approved (houses require blueprints, and those typically need to be filed with the local city government) whereas most software companies often wing it with a quick description of what to build. FYI, in Sweden there's actually a museum dedicated to a ship that sank 1000 yards on its maiden voyage during a time when shipbuilders didn't use diagrams but were overseen by a master architect
<digresssion on the above mentioned ship (Vasa)>
Incidentally, I happened to spend a few hours at the Vasa Museum in Stockholm earlier this year.
It's a glorious 17th-century wooden ship. In 1628, it sank like a stone, after travelling just one KM on its maiden journey in Stockholm waters; 30 out of the 145 people died. And Vasa stayed under water for 333 years. Then it was recovered in 1961—the only (?) 17th century ship to be preserved. Its ongoing preservation itself a singularly unique scientific project.
It's a spectacular ship, with hundreds of impressive wooden sculptures, carvings and other abilities (displaying the might of the king). 95% of the ship is in remarkably original condition—because, luckily for the ship, the Baltic Sea is not conducive to shipworms.
If you are around the area, definitely take the time visit it. (The small city island where it's located, Djurgården, also has other serene places.)
</end digression>
> FYI, in Sweden there's actually a museum dedicated to a ship that sank 1000 yards on its maiden voyage during a time when shipbuilders didn't use diagrams but were overseen by a master architect
In case anyone got curious, that's https://en.wikipedia.org/wiki/Vasa_(ship)
That is a great story on so many levels (ha). Scope creep, letting non-technical decision override technical ones.
> One example is version control, which wasn't standard until the mid-2000s.
Distributed version control wasn't standard until Git and Hg (2005). Version control has been around for decades. CVS (1986/1990) was popular in the open-source communities, while ClearCase (1992) and others were more common in industry.
It took a while for Git to shake out as the standard version control, but version control in general has been standard industry practice for a long time. Let's give credit where credit is due. The need to track changes to software is not some recent idea.
”Remember that the book was written in the 80s”
Nitpick: 1975 (had to look it up to check whether my memory “it must be older” was right)
Apart from spec-ing the projects before kickoff, do you have any insights about how the engineering teams, outside the SE domain, communicate and co-ordinate?
A software shipped with life-supporting medical equipments, for example, should not have the missing spec problem. Or, I assume so.
You’ve heard about the Therac-25, right?
That one killed lots of people.
Not having the read the book, what is #4 about? Are deadlines not a necessary thing? Don’t most SW teams use sprints to push out features on a regular basis?
#4 states that there's a tradeoff. If you are working on a project, and you can tell that as designed the project will be finished a month late, there are two options: 1) move the deadline or 2) Reduce quality/features. The example used in the book is a cook making omelettes. If it takes 5 minutes to make an omelette and the cook promises it in 4, at minute 3, the cook can either tell you it's actually going to take 5 minutes or the cook can turn up the heat and make a crappy omelette. In SW terms, SW teams are working on a project that is estimated at 8 sprints. At week 4, they're currently on track to finish it in 10 sprints. The SW teams can either remove features, reduce quality (maybe they skip writing tests or code reviews or decide to use a "hacky" solution instead of the "right" solution) or move the deadline.
I didn't read the book but I tend to disagree with 1.
- I've seen a lot of well standardized projects fail. And a lot of disorganized projects succeed. Failure with standardized projects are often attributed to "not followed the standard properly", but if following the standard is so complicated that most teams don't, maybe something is wrong with the standard.
- Retraining is not a bad thing. In the end, employees who have seen many different work environments are generally more skilled. You need to think long term, even considering today's lack of loyalty for employers and employees alike.
- One single language is a stupid idea. Use the right tool for the job. For an experience developer, switching languages is not that hard anyways.
Anyways, I don't think point 1 is bad advise, but we also need to apply point 5 to it ;)
Following a standard is not a guarantee of success. Not having a standard to follow is also not a guarantee of failure.
It is possible to succeed without a standard. And it is possible to fail if you do have a standard.
The key is that having standards (not just “a” standard) usually increases your odds of success. To the point that many feel that having standards is a functional requirement.
The Mythical Man-Month is one of my favorite books about managing engineering projects, and I've found it to be useful beyond just software development. The surgical team principle is one that I pushed for heavily when leading a competitive robotics team in college and found to work quite well. I think that organizing an actual software development team to work in this manner would be difficult, but the limited ability to have many people working on the physical robot at once made the surgical team approach worthwhile.
The book typically referenced the scarce resource of compile time, which is not a concern today. I can't really think of a good parallel to that scarcity in software development today, but in a situation like the robotics team where there was a truly scarce resource to be shared amongst the group (the robot) the surgical team approach worked excellently.
It isn't.
Classical engineering is still following the classical planning principles, with all its pitfalls.
An equivalent lesson would be the widely cited Kanban principle, Toyota. But still rarely implemented, only in crazy experiments. Managers still want to be in control, and still throw money and people on a problem.
But wait, I found a good TMMM case in the film business. There often film projects tend to get over budget. It is explicitly advised not to prolongue the upcoming desaster by throwing more money at it, or wait a few months. You rather fire the director, and finish fast and cheap. https://www.forbes.com/sites/schuylermoore/2019/08/16/busine...
I think the core point about adding more people to a team still holds true. You have to deal with more communication issues.
The book is really about human structures to construct large scale complex technical systems. It can be broadly applied.
The book is still on my todo list... perhaps you could give examples from the book?
"other people set one's objectives, provides one's resources and furnish one's information. One rarely controls the circumstances of his work, or even its goals. In management terms, one's authority is not sufficient for his responsibility. It all seems that on all fields, however, the jobs where things get done never have formal authority commensurate with the responsibility. In practice, actual (as opposed to formal) authority is acquired from the very momentum of accomplishment"
"scheduled progress is poorly monitored. Techniques proven and routine in other engineering disciplines are considered radical innovations in the software engineering"
All deep work.