What happened to the "Surgical Team" pattern from "The Mythical Man-Month"?

Question

Years ago, when I read The Mythical Man-Month, I found lots of stuff which I already knew from other sources. However, there were also new things in there, despite the book being from 1975. One of them was:

The Surgical Team

Mills proposes that each segment of a large job be tackled a team, but that the team be organized like a surgical team rather than a hog-butchering team. That is, instead of each member cutting away on the problem, one does the cutting and the others give him every support that will enhance his effectiveness and productivity.

This is a very interesting pattern for organizing a software development team, but I never found it described in any other Software Engineering book, not even mentioned anywhere.

Why is that?

• Was the "Surgical Team" even unusual back then?
• Or, has it been tried and failed?
  • If so, how did it fail?
  • If not, why don't we see that pattern implemented in today's software projects?

Answer 1

"The Mythical Man-Month" came out the year I started college and was, to use the current vernacular, UUUGE! :-) What you need to understand is the difference in how software was developed THEN vs. NOW. Back In The Day (tm) pretty much all coding was done on paper first, was then keypunched onto (you guessed it) punched cards, then was read in, compiled, linked, executed, results were obtained, and the process repeated. CPU time was an expensive and limited resource and you didn't want to waste it. Ditto and likewise disk space, tape drive time, etc, blah. Wasting perfectly good CPU time on a compile which resulted in (shock and horror!) errors was...well, a waste of perfectly good CPU time. And this was in 1975. At the time that Fred Brooks was developing his ideas, which was the mid-to-late 1960's CPU time was even more expensive, memory/disk/whatever was even MORE limited, etc, etc. The idea behind The Surgical Team was to ensure that the One Super Great Rockstar Developer did not have to waste HIS time on mundane tasks like desk-checking code, keypunching, submitting jobs, waiting around (sometimes for hours) for results. Rockstar Dude Developer Man was to be WRITING CODE. His legion of groupies/clerks/junior developers was supposed to do the mundane stuff.

The problem was that within 2 years of Brooks' book being published the basic ideas behind The Surgical Team were breaking down:

1. CRT terminals and disk files began to replace keypunches and card decks. Computer time became less expensive, multiple computers became available, and job turnaround time dropped dramatically. When I got to college (Miami University, Oxford, Ohio, class of '79, thanks for asking) good job turnaround was about an hour. During finals week - four hours, maybe, sometimes six. (We competed for CPU time with a bunch of commercial companies and universities - and the commercial users got first priority). During my senior year, by which point Miami had gotten out of their "shared computer" arrangement, had their own IBM 370/145 installed on campus, and had a nice HP mini I worked on that acted as an RJE station we could turn mainframe jobs around in five minutes or less. It was now worthwhile to bang your code in on the HP, send it from the HP to the mainframe, twiddle your thumbs/smoke a cigarette, and get your output back long before you could finish desk-checking your code.

2. The Surgical Team has as its basic premise the idea that you (or "management", god help us all) can identify The Rockstar Surgical Developer Dude. In fact, I doubt that's possible. There are rockstar developers, everyone knows it - studies have shown differences in productivity between the best and worst developers of as much as 2000% - but identifying that person without having them write code over a long period of time is most likely impossible. The only way to know if someone is a rockstar developer is to have them actually develop code - but if they're NOT the Rockstar Surgical Developer Dude they'll be doing exciting things like desk-checking his code, keypunching it onto cards, and schlepping boxes of punched cards down to the Job Entry department, then standing around waiting for results so they can schlep them back to Mr. Rockstar Surgical Developer Dude instead of learning to code the only way that really works - by writing code, debugging code, and etc. Back In The Day (tm) there were no programming contests, there was no Stack Overflow, you didn't have a PC you could go write code on whenever you felt like it, there were no Algorithms For Idiots books - the only way to learn programming was to go to school and major in something where you got to do a bit of programming. But programming per se was not taken seriously, and it was assumed to be something people didn't want to do. In my first college course (SAN151 - Introduction To Systems Analysis, Dr. Tom Schaber - thanks, Tom :-) we were told by the instructor that "...we just had to face the fact that we'd have to spend a couple of years as programmers before we could become systems analysts". "Two years?", I thought. "I ONLY GET TO DO THIS FOR TWO YEARS?!?". I was seriously bummed. Thankfully he was wrong and I've been coding pretty much ever since. :-)

3. The Surgical Team assumes that programmers are a relatively rare resource. It actually took a few more years, but with the advent of PC's in the early 80's programming became something that any geek could get involved in. The price of computers began to fall, the price of development tools began to fall, and it was all hail Turbo Pascal - by today's standards it wasn't much but at the time it was a complete Pascal IDE for about 40 bucks, which was absolutely nuts! Now ANYBODY could get into programming - if you could afford a computer, and when IBM decided to put the PCjr (yep, my first PC was one of IBM's biggest mistakes :-) on sale for about $500 to get rid of those turkeys, cash-strapped geeks everywhere skipped their rent payments for a month ("Yeah, uh, I know, but I, uh...broke my uuvula and had to have surgery and...uh...yeah, next week, no problem, thanks, man...) and sucked 'em up at fire-sale prices. Then spent more than we paid for the computer on add-ons to make it usable. ("Yeah, man, next week, for sure, probably..." :-).

What makes me really sad is that even today, if you ask people if they've ever read "The Mythical Man-Month" or understand its principal lesson ("Adding resources to a late project makes it later") they give you a blank stare - and then proceed to make the exact same errors as were made All Those Years Ago during the development of OS/360. Everything old is new again... :-}

Answer 2

There are some aspects of that concept that are sometimes implemented today, there are other aspects that are avoided.

Keeping teams small is one of the basic features of Agile Methods, but is also practiced outside of Agile.

Cross-functional teams are also a staple of Agile, but common outside of Agile as well.

The role of the Program Clerk is largely subsumed by computerized systems such as Version Control Systems, Software Configuration Management Systems, Change Management Systems, Document Management Systems, Wikis, Continuous Build Systems with Artifact Repositories, and so on. I mean, can you really imagine paying a full-time employee to print out source code, and manually index and file it?

Similarly, the role of a System Administrator (not part of Mills's Surgical Team, but part of a typical cross-functional team of the last years) is being obsoleted by concepts like DevOps (absorbing the role of Sysadmin into the role of Software Engineer), Platform-as-a-Service, Infrastructure-as-a-Service, and Utility Computing (making the role of Sysadmin "someone else's problem"), or Infrastructure-as-Code (turning System Administration into Software Engineering).

One of the aspects that we try to avoid today, is that at most two people understand the system. Only the surgeon is guaranteed to understand the system fully, the co-pilot may or may not. This gives a bus factor of between 1 and 2. If the surgeon gets sick, the project is dead. Period. The Agile answer to that is Collective Code Ownership, which is the exact opposite of that model: nobody is singularly responsible for any part of the system. Instead, everybody is responsible for everything as a group.

Lastly, there are some assumptions baked into that concept, which are outdated. For example, even though it is not stated explicitly, the team is set up in a way in which only one person in the team (the surgeon) actually has a computer. That is, of course, because at the time the article was written, even the idea that an entire team would have one computer for themselves, let alone one person on the team, was a stretch. (Even in 1980, when Smalltalk was released, one of the things that contributed to its failure was the fact that the system was set up such that every developer and every user had their own computer – completely unthinkable at the time.)

So, in short: I don't think the concept has been implemented exactly as described, but some aspects of it definitely are implemented, some aspects are seen as undesirable and actively avoided, some are obsolete, and some are Probably Good Ideas™, but nobody does it.

Answer 3

It used to be, a college education was something unique, and engineers were among the chosen few. Computers were expensive, and teams worked on projects with defined business RoI. These were not very common.

What happened was micro computers, ubiquitous undergraduate education, and computer systems that don't even need University degrees to make progress with. Also, what happened was shifting economics and rising cost of labor.

The economics of a 8:2 support:engineer ratio don't make sense anymore. Engineers must be their own support. A modern human being with sufficient education and skills to be effective attached to a development team is too expensive to not be doing their own development of some sort.

(A related economics term is "the cost disease of the service sector.")

Answer 4

This patterns sounds a lot to me like Mob programming:

The whole group (QA, developers and even Product Owner if needed) is working at the same time in the same problem. No stand up, high communication, directly deployed into live.

From http://codebetter.com/marcushammarberg/2013/08/06/mob-programming/

The basic concept of mob programming is simple: the entire team works as a team together on one task at the time. That is: one team – one (active) keyboard – one screen (projector of course). It’s just like doing full-team pair programming.

See it in action here: https://www.youtube.com/watch?v=dVqUcNKVbYg

Answer 5

This team model is mentioned again in Rapid Development - Taming Wild Software Schedules by Steve McConnell on page 305. There it is called the Chief-Programmer Team.

This model arose because there was a genius on the team and computing resources were limited. It's fallen out of favor because genius is rare, and with ubiquitous computers and distributed version control we have room for many hands at the operating table.

Other references:

Baker, F. Terry. "Chief Programmer Team Management of Production Programming," IBM Systems Journal, vol. 11, no. 1, 1972, pp. 56-73.

Baker, F. Terry and Harlan D. Mills. "Chief Programmer Teams." Datamation, Volume 19, Number 12 (December 1973), pp. 58-61.

Answer 6

My guess is that most small self-organizing teams will tend to settle into a de-facto surgical team model anyway.

The last two teams I've been on have tended to consist of three or four people, usually one senior (surgeon), an intermediate (co-pilot) and a couple of juniors / specialists. Some of the roles in the surgical team as mentioned by Brooks nowadays are filled out by Scrum masters and sysadmins or cloud providers. Remember that source control barely existed at the time, let alone something as powerful as git.

Think of Bezos' two-pizza rule. That's your self-organizing surgical team right there.

Answer 7

There was a paper out of HP that suggested something similar:

• Each software engineer would require multiple managers and multiple support people.
• There should be a technical writer, tester, build manager, and tool-maker for each engineer.

The paper was in pre-web days, and was brought up from time to time as funny. Each year it was brought up, the commentary moved a bit more from "so ridiculous its funny" to "maybe we should do that".

Actual tests are notoriously hard to design, so it probably remains opinion. There might exist some surveys of projects and their completion rates.

Answer 8

I wonder how much of the need for a surgical team has become redundant because of the rise of the Internet, integrated development environments and software development kits, which can take on a lot of the functionality Fred Brooks attributed to the surgical team, including:

• Surgeon: a programmer
• Co-pilot: pair programmers, co-workers, online communities such as StackExchange or IRC
• Administrator: role generally taken by a software project manager
• Editor: IDEs integrating documentation-generators like Javadoc or Doxygen; documentation from software development kits
• Secretary: e-mail client, project management tools such as issue trackers and pull requests, company chatrooms and mailing lists
• Program clerk: IDE storing information on the project design, with the added ability to refactor code; documentation and examples from software development kits
• Toolsmith: the entire open source community
• Tester: on an immediate basis, test suites and testing libraries. But of course a separate QA process is necessary for production code.
• Language lawyer: online documentation, StackExchange

Answer 9

I think you need to look at the premise of The Mythical Man Month. Hiring more programmers only makes a problematic/overdue software project get worse. The problem is in communication and getting newly added programmers up to speed on the project (takes time from existing development), technology and sometimes the domain itself.

One well supported programmer eliminates many of the communication time and coordination. Let's say you hire a consultant for Technology X. Instead of bringing this consultant up to speed on the project enough to where this individual could do all the coding in that area, he just coaches the existing developer to the point where he can get something built with some supervision.

One reason you don't see much of this is because most software gets written by one person anyway. Teams divide up the work and everyone goes and does their thing. Pair programming, reviews and anything that smells of micromanagement is frowned upon. Many do not see programming as a team sport. One person solves a given problem with some consideration for the over-all constraints.

Answer 10

I would argue that the more we separate design, implementation, testing, documentation, build, deployment, operations, etc into unique roles done by specialists, the more we are following the "surgical team" philosophy (though maybe not in exactly the way described).

In my experience, the devOps philosophy that every person should be capable of every task is a return to the hog-butchering model (not to say that it's bad, just different).

Answer 11

As a programmer that often filled the roles of DevOps and Build Master I felt that I often ended up in that position of being the surgical team.. err... guy in the team. As a build master I had overview on the whole code and was the first line when it failed. Oftentimes I would just fix it myself.
I was often the one writing these metrics systems and measure the hotpoints in the code, parts that would fail more often, that attracted the most bug reports etc. I did not just published the results to the team I would analyse them too, find the kink that caused issue and proposed solutions and architectural changes to address this.

As a DevOps I would automate huge swathes of process and overhead. I'd research technologies and tools that would make life easier on the team, the whole team, from developers, QA testers IT ops all the way up to management. My role was to understand the process, yes; but by keeping my eyes fixed on the team (the actual humans) using (suffering through) that process I was able to distil it to a point of making it completely transparent while still getting a swath of useful data to get an objective view of that ever elusive "big picture".

It's an ungrateful position to have and likely why it is shunned so much. I know I did my job well when nobody noticed that process, when nobody gave a thought about the build pipeline. So yes, a well oiled machine is quickly taken for granted. But I knew, in fact I measured, the multiplicative impact this work can have on a team's productivity and it is well worth the investment.

So yes, I think that role is still very much alive today, though admittedly it did evolve from what it was back then.