The Mythical Surgical Team

The Mythical Man-Month is a masterpiece on the subject of software project management. Although he wrote the book in 1972, the author, Dr. Fred Brooks, is still quoted by software developers and managers today. "Plan to throw one away," "Take no small slips," and "Adding manpower to a late software project makes it later," have long since become conventional wisdom. We don't always follow the conventional wisdom, mind you, but we can quote it.

It is amazing how relevant The Mythical Man-Month still is, but Chapter 3 struck me at first as quaint if not downright bizarre. The chapter is called "The Surgical Team". In it Dr. Brooks promotes an idea first developed by IBMer Harlan Mills in 1971. The idea is to organize large software development projects into multiple "surgical teams". Each team is headed by a chief programmer, the surgeon, who does most of the delicate work. In a real surgical team, the surgeon does all of the cutting and stitching. He is supported by a staff of specialists with more mundane roles. In the Brooks/Mills scheme, the chief programmer does most of the programming. He has a staff of nine people to take care of mundane tasks.

Brooks goes into a lot of detail about the supporting roles. I won't give all the details, but here is a summary:

• The copilot is the chief programmer's right-hand man. He can do the development work but he has less experience. He often represents the team at meetings and otherwise off-loads the chief programmer from duties other than pure development.

• The administrator manages people, hardware and other resources required by the team.

• The editor is responsible for editing documentation written by the chief programmer.
  

• Two secretaries -- one each for the administrator and editor.
  

• The program clerk keeps all the records for the project including source code and documentation.
  

• The toolsmith builds specialized programming tools to the chief programmer's specifications.
  

• The tester develops and runs both unit tests and system tests.
  

• The language lawyer is an expert on the computer languages used by the chief programmer. He provides advice on producing optimal code.
  

My first reaction to this list was, he's crazy. It doesn't take nine people to support one good software developer. Then I realized it may have taken that many people to support one good systems programmer in 1972. And you know what? Many of the above roles have since been automated by software itself. We don't need a language lawyer anymore. We have optimizing compilers, PMD and other tools. We don't need a programming clerk anymore. We have easy-to-use source code control systems, discussion databases, and document repositories. We don't need a toolsmith anymore. We have plenty of tools to choose from.

My point is that Brooks's vision has largely been realized, but in a way he didn't predict -- by automation. We haven't hired a support staff for each chief programmer. We have automated most of the surgical team's tasks.

Does that mean each developer is a self-contained surgical team? Unfortunately, the answer is no -- no more than hiring a real surgical team would make me a surgeon. A surgeon is made by training and experience, not by the resources at his disposal.

In The Mythical Man-Month, Brooks establishes at least two central premises before promoting the surgical team concept:

1. The main problem with large software development projects is one of communication. The more developers on the project, the bigger the communication problem is.
    
   
2. There is a huge productivity gap among software developers. The good developers are very, very good. The bad ones are very, very bad.

The whole idea of building multiple surgical teams is to reduce the effects of these two phenomena. In other words, minimize the number of hands in the code, make sure only the best, brightest and most productive developers are coding, and give these developers all the resources they need. I think automation has solved the resource part of the equation, but in my experience, software development managers still misunderstand the rest of it. We tend to build large teams of developers with a wide-range of training and experience, and then reduce them to interchangeable man-months. This is a recipe for disaster.

My advice is to go back to the drawing board. Hire the best developers to do the work. Pair them with more junior developers for the purposes of training and insurance -- not necessarily to do the work. And, at all costs, keep teams as small as possible.