3

I'm reading through The Mythical Man Month for the first time. In it, Fred Brooks* proposes a model of software development based on how a surgical team works. There is a "surgeon" (a senior developer) who does almost all the design and implementation work, a "copilot" who discusses these ideas with the surgeon and occasionally does some minor coding, a "toolsmith" (dev ops), a language expert, and some other administrative workers.

I can't but help be struck by the fact that, despite the great fame of The Mythical Man Month, I have never seen or even heard of an office that actually operates on that model. This is despite the meteoric rise of the tech industry and the cult of the "rockstar programmer" that fashionable among startups today.

And so I was wondering if this is because the surgical model has become obsolete in any way. After all, we now have advances like version control (making one of his administrative roles obsolete), optimizing compilers (possibly making the language expert obsolete), and agile development (which may not make anything obsolete, but seems substantially different from the waterfall method that people used in those days).

The question, then: Has there been any research on the efficacy of Brooks' "surgical team" model in the era of modern software development, with agile processes and modern tools? What does today's research say is the most effective team structure?

*Credit where credit is due: technically, Brooks is summarizing earlier research by Harlan Mills and F.T. Baker. I am using Brooks' name only because his name is more recognizable.

closed as off-topic by gnat, BЈовић, user40980, Kilian Foth, Doc Brown Jun 24 '15 at 18:54

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – gnat, Community, Kilian Foth, Doc Brown
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    What does today's research say is the most effective team structure? - it says this: "there are no silver bullet among software development methodologies. They all got cons and pros." – BЈовић Jun 23 '15 at 14:41
  • This was the "Chief Programmer Team" concept, originally described by Harlan Mills in 1971. Brooks picked it up. The fundamental issue was that what Mills called a "chief programmer" is what others call a superprogrammer, a Dennis Ritchie, and those kinds of programmers are just not all that common. Remember, 50% of EVERYTHING, including programmers, falls below the median. – John R. Strohm Jun 23 '15 at 15:42
  • I think there are some ways to cast the "superprogrammer" concept in ways that aren't completely impractical. It's not surprising that geniuses are orders of magnitude above commoners. I think the surprising claim being made is that, say, the 75th percentile programmer is 10 times as productive as the 25th percentile programmer. But that may well be false. If so, I'd be interested in the research that shows that superprogrammers are a myth (and therefore the chief programmer model is busted). – HardlyKnowEm Jun 23 '15 at 16:09
  • For reason beyond my understanding, my variant of the same question has not been closed as off-topic, and received quite a lot of very good answers: softwareengineering.stackexchange.com/q/355203/69228 – vog Jan 3 '18 at 12:44
4

The reason you don't see those surgical software teams that much is explained by the way developers are hired and assigned to teams.

Two preliminary conditions for such team are:

  • That there should be, within a company, developers who have different levels with an important gap between the most and the lest experienced ones,

  • And that they are ready to work together.

Let's talk about the first condition. When you look at different companies, developers they hire have similar skill level, experience level and culture. Would you find a talented and experienced developer in a small company which makes PHP websites for local shops? Probably not. You will rather encounter programmers who weren't particularly good at college, and who are not particularly interested by their job. If you do find a junior talented guy, you may be sure that he will leave this company as soon as he finds a better place—and he will find a better place, because lots of companies are looking for talented developers.

Now, would you find a lot of demotivated, inexperienced developers who work just for money at Fog Creek or Valve Software? I don't think so, not only because they won't be hired, but because they won't even try having an interview there.

This means that inside the same company, there will be junior developers and developers with dozens of years of professional experience, but all will still share the same culture and try to work the best they can in some companies, or just work for money in others.

Inside the company, you'll once again notice that the most talented ones want and are encouraged to work together. If there is a challenging project which is crucial for the company, you can be sure that you'll find the best developers there. A boring project which has nothing crucial will instead be given to developers who are slightly less talented. This is a natural way things are done, and this is what will happen if persons themselves decide on which project they will work next, without being formally assigned by the management.

While there is a possibility for the management to force a surgical software team by mixing talented developers with less talented ones, one should note that persons may not get along with each other well. The risk is that since they know that they were put together intentionally by the management, the most experienced person may start to behave like a jerk with his pairs; in turn, less experienced developers may try to avoid confronting the more experienced one. Compare that to a team of people who decided to work together and who respect each other, and you can see why surgical software teams are not a common practice...

In my opinion, surgical software teams may work. In some rare cases, and with persons who know what they are doing and who are ready to work with less or more talented colleagues. This being said, the last decade the trend was rather towards Agile teams of self-organizing persons who have similar culture and similar experience, but specializing themselves in different domains in order to be complementary.

  • +1, this is a culture-of-work thing. Most developers are interchangeable (although will have differences in quality and speed and initial catch up time), while an attempt to replace an anesthesiologist with a different surgeon will end very, very badly. Common projects don't need the insane level of specialization seen in medicine, nor is such specialization documentable in software development. However, the question was Has there been any research...?, rather than Why doesn't it work?, so this doesn't really answer it. – Ordous Jun 23 '15 at 17:34

Not the answer you're looking for? Browse other questions tagged or ask your own question.