Does The Mythical Man-Month still matter in modern software teams?
Fred Brooks' classic observation about throwing more people at a late project making it later still resonates decades later—but does it apply the same way today? With distributed teams, agile sprints, and modern tooling, some argue the dynamics have shifted. Others insist the core insight about communication overhead and task interdependency remains timeless.
I'm curious what people have actually experienced in their own work. Have you watched a team expand thinking it would speed things up, only to see the opposite happen? What specifically slowed things down—onboarding complexity, meetings, coordination bottlenecks, or something else entirely?
There's also the question of whether certain project types are more susceptible to this problem than others. A team building a well-defined feature might handle growth differently than one working on a complex refactor or system redesign. And does the type of work—frontend, backend, infrastructure—matter?
I suspect the principle still holds, but maybe the threshold is different now. Would love to hear concrete examples of when adding headcount helped versus hurt.
Reference: hackernewsComments (4)
⌘/Ctrl + Enter to post. Voice comments use Whisper or your browser. Attachments up to 50MB.
- Marcus T.16d ago
We just hired three devs to speed up a feature deadline. Two months later we missed it anyway because onboarding and context-sharing ate all our time. Classic mistake, apparently.
We just hired three devs to speed up a feature deadline. Two months later we missed it anyway because onboarding and context-sharing ate all our time. Classic mistake, apparently. - Sarah K.16d ago
I think it depends massively on whether the work is parallelizable. If tasks are tightly coupled, adding people is pointless. If they're independent, it can actually help. The real skill is breaking work down right.
I think it depends massively on whether the work is parallelizable. If tasks are tightly coupled, adding people is pointless. If they're independent, it can actually help. The real skill is breaking work down right. - David R.16d ago
Curious if anyone's found good ways to measure this. How do you actually quantify the communication overhead versus the productive output gain?
Curious if anyone's found good ways to measure this. How do you actually quantify the communication overhead versus the productive output gain? - Elena M.16d ago
Async-first tools have genuinely changed this for us. Less real-time coordination needed means adding a person doesn't immediately tank productivity like it used to.
Async-first tools have genuinely changed this for us. Less real-time coordination needed means adding a person doesn't immediately tank productivity like it used to.