A fly in the ointment

From Chapter 3: The Surgical Team

Excerpt
...one does the cutting and the others give him every support that will enhance his effectiveness and productivity.(p. 35)

Brooks says that some jobs are too large for a small team. However, if you have a large team, Brooks' Law kicks in adding significant communication overhead, bogging down progress and bloating cost and schedule. What's the manager of a large software project to do?

Brooks' Law

Brooks has a grand plan. In subsequent chapters (4, 5, 6 and 7), he will offer a solution for managing the large project. This remedy is built on the Surgical Team concept.

What is the Surgical Team exactly? Brooks spells it out in Chapter 3 (see Picking the Archetypes for the Surgical Team for a summary).

There are a two key concepts of the Surgical Team.

• The job gets divided up into tasks that can be handled by a "10-man programming team"
• Each task produces a system is the "product of one mind," the Chief Programmer. As Brooks put it, "one does the cutting."

To make this work, Brooks prescribes the following:

• The Chief Programmer will be supported by 7 specialists (plus 2 secretaries) who are each responsible for some part of the "design and implementation"
• Each specialist communicates to the rest of the team through the Chief.¹ This cuts the number of communications path by over 80%.
• Of the 7 specialists, only one, the co-pilot, is a programmer and he "is not responsible for any part of the code."

In other words, it appears that Brooks is suggesting that for each team of 10 there be only ONE programmer. To first order this means that a staff of 100 is needed to support 10 programmers. As Brooks puts it, "So it is possible to put 200 people on a problem and face the problem of coordinating only 20 minds..." (page 37.)

Admittedly the Surgical Team as described is anachronistic. Many of the duties that previously required staff, like the 'Program Clerk,' are now done with software tools. But the main point is that the Chief is king and the co-pilot is prince; together they rule a small kingdom of specialists who do not program. A variation of the Chief-Copilot tuple is promoted by devotees of Agile Programming as pair programing.

But remember, the purpose of the surgical team is to provide an organizational remedy that solves the 'big team' problem for projects that require 10's if not 100's of programmers. (see Small is beautiful, but not applicable.) Here's where the Surgical Team salve gets sticky.

What happens in the common case that a the job cannot be partitioned into a thin layer of one-man tasks? Does the Surgical Team recurse into a hierarchy of Surgical Teams? Would you restrict a Chief Programmer on one leaf task from talking to a Chief Programmer on another leaf task? If not, the communication paths would multiply geometrically obviating the need for the surgical team.

On the other hand, if all communication was routed up the Surgical tree, there would most certainly be a communication and decision bottleneck that would be worse than any cure. As Brooks puts it, "'Schedule disaster, functional misfits, and system bugs all arise because the left hand doesn't know what the right hand is doing.' Teams drift apart in assumption" (page 235)

We had just that sort of bottleneck on my last NASA project. Our chief engineer insisted on being part of every decision. In just a month, our work ground to a dead standstill; our obligations did not. In order to the make the progress needed to meet our commitments, our experienced programmers simply completed the work without discussing it with the technical leadership. It was the only rational thing to do.

You won't find a Chief Programmer in the group

And, then there's the question of how to staff a large project. Brooks was clear that the product should only be programmed by Chief Programmers with possible small contributions from the Copilot. (So, you might say the Surgical Team has 1.1 programmers.) He describes the Chief as a developer with "great talent, ten years experience, and considerable systems and application knowledge..." (page 32). How would you staff such a team? Where would you find 10's or 100's of men and women with that skill level? And, if you did find them, how could you retain them between assignments?

It's possible that Brooks does not really mean there should only be 1.1 programmers on the surgical team. In chapter 7, Brooks discusses how senior programmers, development programmers, project programmers, junior programmers and trainees would fit into an organization. Why bother with these Indians if all you need is Chiefs? Of course if he's not serious about 1.1 programmers per team, then the bug-a-boo of Brooks Law reasserts itself.

Here's the rub. There is no easy way around Brooks' Law. The Surgical Team does not alleviate the large-team problem. There's a fly in the ointment.

I suspect when the Mythical Man-Month was written, a Surgical Team with 1.1 programmers made sense. Today, it's a flawed concept. So for purposes of this blog, I'll stretch the meaning of the Surgical Team to include as many programmers as the Chief Programmer needs to complete the task on time. Of course that means there may be no escape from Brooks Law.

---

^1. For a diagram, see the online version Text page 36 which is pdf page 50.
^2. Brooks defines architecture as "the complete and detailed specification of the user interface." (p.45) In this case "user interface" refers to a programming interface. Today, software architecture refers to a a much broader scope of concerns.