Why adding more programmers to a late project makes it later
The gist of Chapter 2 is this: For the typical software development project, at some fairly small number of workers (designers, developers, testers, infrastructure engineers) adding one more worker makes the project take LONGER!
First, software development is not easily partitioned into smaller and smaller discrete tasks because a software product defines the interactions of many complex objects; from logical business objects (e.g. customers, products, orders) to computer components (e.g. database rows, network nodes, security certificates), which cannot be easily disentangled.
Second, the time consumed by interpersonal communication among the workers needed to coordinate the complex interrelationships of the software objects and computing infrastructure consumes an increasing portion of the available effort as the team grows. Therefore, as team size increases, each worker spends a larger percentage of their time talking and listening (and maybe reading but no one reads) than completing their assigned tasks. Less and less work gets done by more and more people.
Partitioning and Communication
Brook’s illustrated this problem using graphics. He classified tasks as more or less partitionable and requiring more or less intra-project communications. Sometimes a business manager without software development experience has, lurking in their mind, an unspoken assumption about the nature of the software development task tending toward partionable and solitary.
The following summarizes four types of partionable tasks. The graph of each type of partionable task plots the number of workers (Men as in the Mythical Man of the book’s title) on the X-axis and the resulting Duration of the project on the Y-axis.
Completely Partitionable task: A completely partitionable task can be assigned to one or many workers without change in productivity per worker. Imagine digging a ditch.
Non-partitionable task: Duration is unaffected by additional workers. Two ovens cannot bake a pie in half the time. Nine women cannot give birth in one month.
Partitionable with Communication: Any task requiring training of new workers and coordination of effort requires communication. Two landscape muralists can paint a mural together faster than one alone. But, they better talk about the scene they are painting before they start and keep talking as they go.
Semi-Partitionable with Complex Interrelationships: Communicating about complex objects with even more complex interrelationships among a growing number of workers reduces the amount of time available for the original workers to do their work. The experienced workers spend time training and cajoling the newbies. Everyone spends more time explaining themselves to everyone else. (Shannon’s ‘Information Theory’ sheds light here. I’ll reread that book as well so that you, Gentle Reader, need not do so.)
In the preceding, Brooks’ essential point is illustrated in the fourth row: The graph of a project comprising semi-partitionable tasks with complex interrelationships illustrates how increasing the number of Men does not produce a decrease in the number of Months.
Why, since this relationship has been known since 1975, do managers nevertheless add more people and are surprised by slowing progress? Well, not everyone has read MMM.
The Effect of Proliferating Communication Channels
Communication overhead can be thought of as the number of pairs of workers who have to communicate; sometimes called communication channels. Expressing this relationship mathematically, Brooks relies on prior work from Information Theory:
If each part of the task must be separately coordinated with each other part then the communication effort increases as: (where n is the number of workers)
Communication Effort = n(n-1)/2
Dr. Frederick P. Brooks Jr, The Mythical Man-month, 1975
Let’s do a bit of math. A team of 2 has exactly 1 communication channel.
Team of 2 = 2(2-1)/2 = 1 communication channel
Team of 5 = 5(5-1)/2 = 10 communication channels
Team of 10 = 10(10-1)/2 = 45 communication channels
Do teams of 10 really spend 45 times as many minutes communicating as a team of 2? Good question.
There are plenty of steps we can take to reduce this communication explosion. Daily (or even twice daily) stand-up meetings can reduce the interruptive nature of pair-wise communication. Also, pair programming can allow for communication between pairs rather than between individuals. And, larger teams instinctively feel the need for documentation which can, if done well, reduce the need for pair-wise communication.
Nevertheless, larger teams inevitably have turn over which drives up the hours required for training the new guy.
Five Lessons From Chapter 2
Brooks posited this relationship in 1975. Is it still relevant? It is certainly true that the bulk of individual human tasks required by a software development project in 1975 have been abstracted, encapsulated, hidden and/or automated. Does that mean that in general teams can be larger or smaller?
It seems to me, Dear Reader, that the punchline here is that technology allows teams to advance along a complexity front. That is, the same number of workers can control a greater and greater span of complexity.
BUT, the number of people who can work together remains rather static; somewhere between the size of a basketball team (5) and a soccer team (11). Sorry, rugby fans, but 15 on a software development team seems a bit outside the observable limits.
So, if effective team size is relatively fixed because of the semi-partitionable, highly complex nature of software development, what can we do to increase team productivity?
The Top X%
First, hire workers who each can handle more complexity. Obvious. But, what is less obvious is how quickly a team with lower ability to handle complexity becomes ineffective. Hence, today’s emphasis on hiring the top X%. This seems to be Google’s default strategy.
Second, if team size must be relatively fixed and any useful product necessarily has a very large scope (see MMM page 4) then narrow scope and strict adherence to good architecture (abstraction, encapsulation, hiding, etc.) are critical. Hence, today’s emphasis on API-first development. This seems to be Amazon’s default strategy which is proving to be more scalable than hiring the top 1%.
Third, communication about ‘the way we do things here’ consumes a lot of time. There’s something to be said for assembling a team who already share the same assumptions and training which might be gained from a shared experience like graduating from the same computer science program or working at the same company. When a development team talks about ‘cultural fit’ this is probably what they are talking about without being aware of the underlying reason for their feelings.
Fourth, I’ve noticed that when a software development team reaches a certain size; more than 5, less than 11, the rejection rate of new-hire candidates by the current engineers approaches 100%. Perhaps this is because the current engineers feel the increased time consumption of communication but have no explicit way to talk about it. Hence, they simply reject expanding the team.
Fifth, each team member today commands vastly more complexity than 45 years ago. So, each team member must act like the tools he uses; he must abstract, encapsulate and hide most of that complexity from teammates. This increases the premium for good communication skills. It also means that if an underlying tool fails to behave as expected there’s a big penalty to pay.