Adding People to a Late Project Will Make It Later

Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them.

Brooks wrote this in 1975, and here we are, fifty years later, still answering customers about why doubling the number of developers will not magically cut the schedule in half. As Brooks says, good cooking takes time. If a pizza needs twenty minutes at 250 degrees, you cannot speed it up by blasting it for ten minutes at 500. You don’t get a pizza. You get charcoal.

The real trouble is that software is not something you can rush with more hands. One new person joins the team and suddenly everyone needs to pause and explain what has been built, why it was built that way, and which decisions were made three versions ago. The newcomer has to absorb the whole story, and the rest of the team has to retell it. Progress slows, not because people are lazy, but because understanding simply takes time.

What keeps me sane is holding on to conceptual integrity. I don’t build operating systems, but I do build large enough e-commerce systems. And in all these years, the only thing that consistently works is having one architect who owns the entire picture. Others can lead backend, frontend or data, but one person has to carry the whole idea so the system feels like one thought, not a collection of unrelated components. When that clarity is in place, communication becomes smoother. Not effortless, but manageable.

Modern architectures try to make this easier. Microservices, modular designs, composable systems. They let teams work independently without running into each other. But eventually everything has to come together, and integration waits patiently for the slowest piece. It doesn’t matter how quickly nine modules finish if the tenth one is still figuring itself out. So the old truth continues to hold. Adding more people might increase activity, but rarely reduces time.

Brooks ends the book with a line that has stayed with me. Only a small part of humanity gets the privilege of earning their bread doing something they would gladly do for free. I feel that deeply. I would have written software even without a paycheck, and I’m grateful that this happens to be my work.

# About the Book

The Mythical Man Month is Frederick Brooks’ classic reflection on software development, drawn from his years leading the IBM OS 360 project, and the ideas in it feel surprisingly timeless even today.

Buy the book: https://amzn.to/4o9Pjco

This is part of 100 Ideas That Shaped Me from Books I Read