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?
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"?
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.
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.
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.
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.
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.
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?
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 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".
That one killed lots of people.
In case anyone got curious, that's https://en.wikipedia.org/wiki/Vasa_(ship)
Nitpick: 1975 (had to look it up to check whether my memory “it must be older” was right)
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.
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>
- 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 ;)
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 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.
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...