The Mythical Man-Month: why adding engineers to a late client project makes it later

The book’s most quoted line is a single sentence: adding manpower to a late software project makes it later. Fred Brooks drew the lesson from his time managing IBM’s System/360 and OS/360.

Fifty years on, it still holds in the place FDEs so often find themselves: the client’s meeting room, after the deadline has slipped and someone suggests “sending two more people over”.

Work as an FDE and sooner or later you will be in that room. The deployment is three weeks late, the client is impatient, and the account team wants to show goodwill by adding headcount. The Mythical Man-Month explains why that reflex usually backfires, and gives you the numbers to push back.

The edition to read is the Anniversary Edition (Addison-Wesley, 1995). According to Pearson, it keeps the essays from the original 1975 printing unchanged, adds new essays reassessing software project management, and includes “No Silver Bullet” (1986).

Brooks’s Law: two costs, not one

Brooks identifies two reasons. The first is easy to see: newcomers need time to ramp up, and during that time they take hours from the very people who already know the project. The second is harder to see: every person added opens more lines of communication.

The book gives the formula n(n − 1)/2 for counting the communication channels in a team. Try it on a mid-sized engagement: four engineers have 4 × 3 / 2 = 6 channels. Add two people to make six and you have 6 × 5 / 2 = 15 channels. Headcount rises 50%; channels rise 2.5 times. With 50 programmers, the figure is 1,225.

Now put that calculation into a hypothetical. You are deploying a data pipeline for a client, it is already three weeks late, and two new engineers have been sent over.

In the first week you sit explaining the client’s schema, the process for requesting access and why that other table must not be touched. In the second week they start coding, but every decision now passes through 15 channels instead of 6.

By the third week, the project has still not gained a single day.

So the first thing to do at the client is to go back to the meeting with that calculation and a different proposal: cut whatever is not needed for the next milestone, and keep the current team focused.

The surgical team: concentrate effort around the best person

The second idea worth keeping is the “surgical team”. One highly skilled lead programmer writes the critical parts himself, and everyone else plays a supporting role. Brooks sets this model beside a blunt observation: “good” programmers are five to ten times as productive as mediocre ones.

Many FDE engagements already run this way without anyone naming it: one person holds the full picture of the client’s context and the integration architecture. The lesson from Brooks is to protect that person.

The five-to-ten-times figure is a general observation about the spread between programmers, not a measurement of any individual; but if half the lead’s day goes on re-explaining things to newcomers, you are wasting precisely the person the whole engagement depends on.

The second-system effect: version 2 is the most dangerous

The third idea fits the period after go-live. Brooks warns that an architect’s second system tends to be stuffed with the features deferred from the first. He called it the most dangerous system its designer will ever build.

For an FDE, this trap usually opens right after the first successful deployment. The client is happy, you are confident, and the “next version” list suddenly becomes the next version’s scope. Reread that list and ask of each item: does it solve the client’s problem, or is it just emotional debt left over from last time?

Cutting scope can go wrong too

Having grasped Brooks’s Law, many people stumble at the next step. The most common mistake is cutting scope inside the team without agreeing a new milestone with the client. The team believes it has done the right thing, the client still expects every feature on the original date, and by handover day the trust is gone.

The second mistake is using the law as an excuse to refuse all help. Brooks is talking about newcomers who must ramp up and about new communication channels, so the question to ask is whether the person being sent over adds to either.

The safe approach is to write it down: which items are dropped, what the new milestone date is, and have the client confirm before the team changes plan.

Who should read it, and in what order?

The book suits engineers with two or more years of experience, especially those starting to lead engagements or who have to discuss progress with clients. InformIT notes that few books on software project management have proved as influential and timeless. Even so, do not read it as a textbook, as many of the examples date from the mainframe era.

Recommended order: the essay on the law and the communication formula first, then the surgical team, then the second-system effect. Leave “No Silver Bullet” and the 1995 additions until last, to see Brooks reassess his own work.

When preparing for an FDE interview, do not just quote Brooks’s Law. Tell the story of a time you refused extra people and cut scope instead: how late the project was, what you dropped, and which milestone you hit. Put all three details on your CV, with the weeks of delay and the milestone hit given as specific numbers.

A formula from 1975 will not make a client’s project run faster. But it gives you enough of an argument not to make it slower.