What one programmer can do in one month, two programmers can do in two months. — Fred Brooks

What one programmer can do in one month, two programmers can do in two months.

Author: Fred Brooks

Insight: This cutting observation about teams reveals something most people discover the hard way: more hands don't automatically mean faster results. When you add another person to a project, you don't just gain their productivity—you also inherit the overhead of coordination. They need to understand what's already been decided, who's doing what, where the pitfalls are. Someone has to explain it all, answer questions, smooth out conflicting approaches. That time comes directly out of the work time. The real insight isn't that teamwork is bad. It's that there's a threshold where communication costs actually outweigh collaboration gains. This applies far beyond programming—think about group projects at work, family decisions, or creative ventures. The temptation is always to throw more people at a problem when we're falling behind. But sometimes the most effective move is keeping the team lean and decision-making tight. What makes this especially relevant now is how easy it's become to add collaborators remotely. We can pile people into Slack channels and video calls almost costlessly. Yet those hidden communication taxes still exist—they just wear different clothes. The best teams aren't usually the biggest ones. They're the ones that move with clarity about who owns what and why.

Source: The Mythical Man-Month, p. 16, 1975

What one programmer can do in one month, two programmers can do in two months.

Fred BrooksThe Mythical Man-Month, p. 16, 1975

More people, slower progress

This cutting observation about teams reveals something most people discover the hard way: more hands don't automatically mean faster results. When you add another person to a project, you don't just gain their productivity—you also inherit the overhead of coordination. They need to understand what's already been decided, who's doing what, where the pitfalls are. Someone has to explain it all, answer questions, smooth out conflicting approaches. That time comes directly out of the work time.

The real insight isn't that teamwork is bad. It's that there's a threshold where communication costs actually outweigh collaboration gains. This applies far beyond programming—think about group projects at work, family decisions, or creative ventures. The temptation is always to throw more people at a problem when we're falling behind. But sometimes the most effective move is keeping the team lean and decision-making tight.

What makes this especially relevant now is how easy it's become to add collaborators remotely. We can pile people into Slack channels and video calls almost costlessly. Yet those hidden communication taxes still exist—they just wear different clothes. The best teams aren't usually the biggest ones. They're the ones that move with clarity about who owns what and why.

Comments

Sign in to leave a comment or reply to one.

Sign in

Fred Brooks

Fred Brooks is an American computer scientist known for his work at IBM and later as a professor at the University of North Carolina. He is best known for managing the development of IBM's System/360 mainframe computer and for authoring the influential book "The Mythical Man-Month" on software project management.

Graph

Related