
Ask HN: How relevant is The Mythical Man-Month outside the software industry? - joddystreet
Or, what are the equivalent lessons from managing engineering projects, outside the software domain?
======
ken
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"?

~~~
juped
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.

------
RNeff
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!

~~~
joddystreet
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".

~~~
twunde
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

~~~
majewsky
> 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)](https://en.wikipedia.org/wiki/Vasa_\(ship\))

~~~
sitkack
That is a great story on so many levels (ha). Scope creep, letting non-
technical decision override technical ones.

------
baylessj
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.

------
rurban
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...](https://www.forbes.com/sites/schuylermoore/2019/08/16/business-
issues-under-film-licenses/)

------
tmaly
I think the core point about adding more people to a team still holds true.
You have to deal with more communication issues.

------
sitkack
The book is really about human structures to construct large scale complex
technical systems. It can be broadly applied.

------
jppope
The book is still on my todo list... perhaps you could give examples from the
book?

~~~
joddystreet
"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"

------
crb002
All deep work.

