171

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?
vog
  • 1,424
  • 2
  • 11
  • 10
  • 12
    I would say this can only bring opinion-based answers. My knee-jerk opinion is that no "software engineer" wants to be seen as "support" role. They want to be seen as equal to everyone else on the team. This may be related to the fact, that majority of software developers are extremely young. Most teams don't have anyone who could claim seniority and be considered the "surgeon" of the team. – Euphoric Aug 06 '17 at 17:21
  • 44
    A potential problem that I see when you intentionally try to organize a team that way is to correctly identify who the surgeon should be. – Bart van Ingen Schenau Aug 06 '17 at 17:21
  • 9
    @Euphoric Don't forget some of the managers that delude themselves into thinking that they already have their super-uber-guru-star-surgeon programmer, so why employ all of those support peasants in the first place? I've seen my share of mgrs that didn't show evidence of understanding software development and its inherent challenges while "managing" software teams, or much else beyond their colorful excel spreadsheets, unfortunately (usually, though not always, people close to retirement). – code_dredd Aug 06 '17 at 19:35
  • 1
    I would (at this point in time weakly) advocate for something that's superficially the opposite for most application domains. Namely, your "surgeon(s)" should be building the infrastructure that supports others. To horribly mix metaphors, your surgeons should be building the chainsaws so that the people actually cutting down the trees are more efficient than they would be with axes. The "surgical team" approach seems like it might be more appropriate for application domains where a very high level and rare expertise is required to succeed at all. – Derek Elkins left SE Aug 07 '17 at 01:20
  • 7
    It may have something to do with the fact that "surgery" is one of the most *backward-looking* branches of medicine - indeed, it's a well known joke in the UK that surgeons spend 7 years studying so they can be called "doctor", and then a further 7 years so they can be called "Mr" or "Mrs" again! In fact *reorganizing* surgery to improve its performance by following the "best practice" of other industries with much lower error rates, etc (in particular, civil aviation) is an ongoing effort within the medical profession. ... – alephzero Aug 07 '17 at 02:55
  • 5
    ... "Old-school" surgical teams haven't even progressed as far as using things like checklists, or any other documented "standards" for how they operate, let alone ideas like "agile development." If the "hog-butchering methodology" was good enough for their predecessors for the last few centuries, why change it now? ;) – alephzero Aug 07 '17 at 03:03
  • 6
    @alephzero: Those are a couple of funny claims. Where exactly did you practice surgery? Here, the amount of crap that you call "best practice" takes up a major part of a surgeon's time, and it yields zero benefit. Super smart people [ironic] try ever so hard to improve something they don't understand by adding more bureaucratic crap to it almost every week. The causes of the failure rate that you mention are however not addressed, on the contrary. Almost all failures are due to sleep deprivation, under-education, and over-estimation. Often all three of them together. – Damon Aug 07 '17 at 13:36
  • 1
    It didn't vanish. It's just the name isn't used anymore. I can see this separation everywhere in a good setup: developers, testers, devops, PM/scrum master/product owner, architect, ... Only now people try to combine those roles back into a universal / full stack / t shaped developer concept. – ACV Aug 07 '17 at 17:02
  • @alephzero [The Checklist Manifesto](https://en.wikipedia.org/wiki/The_Checklist_Manifesto), perchance? – user Aug 08 '17 at 12:39
  • 2
    @Damon, "Almost all failures are due to sleep deprivation, under-education, and over-estimation. Often all three of them together." So, just like software engineering then? ;-) – Rob K Aug 08 '17 at 17:19
  • I wonder if a system architect embodies some aspects of the "surgeon" but at a higher level of abstraction – Itamar Aug 08 '17 at 19:24
  • Maybe this approach would work better if software developers were required to have 14 years of training before they started working. I'm not sure that there even is 14 years worth of material to teach that isn't insanely specific though. – Miles Rout Aug 08 '17 at 21:17
  • 2
    One change I have definitely seen is that today it is respectable for a senior developer to write code: Brooks was fighting a culture in which the senior technical people spent their time attending meetings and writing specs, and left coding to the juniors. From about 1985-95, I was too senior to be allowed to write a single line of code. I think that even in large organizations, that philosophy is now gone. – Michael Kay Aug 09 '17 at 10:57
  • (Incidentally I think some of MMM was based on lectures that Brooks gave while on a sabbatical year at Cambridge (UK), where I was fortunate enough to be an undergraduate at the time.) – Michael Kay Aug 09 '17 at 11:01
  • Sounds like [Mob Programming](https://en.wikipedia.org/wiki/Mob_programming) which is becoming a trend again – sakisk Aug 09 '17 at 17:36
  • In my first summer programming jobs, we did something similar to the Chief Programmer Team. During the fall winter and early spring, the permanent programmers did systems analysis and designed programs. During the late spring and summer, student employees were given the designs, turned them into FORTRAN, and tested the code. This was a very good way to learn about design without the responsibility to do it. And it ensured designs were documented. During my second summer I got to do some design of my own. This is still a good way to organize work when experience and skills are unequal. – Theodore Norvell Aug 09 '17 at 18:56
  • 1
    Just out of curiosity, does a literal hog-butchering team really operate in the way described (each member cutting away on the problem)? Or is "hog-butchering team" used merely to suggest lack of care about precise results? – LarsH Aug 10 '17 at 13:56
  • @Euphoric Some of us quite enjoy the support position in a team. The process imposed by the higher-ups weighs you down ? A good support programmer in your team can take the pains away AND strengthen the process. Got a bug that's been haunting you ? call up that support programmer guy, h'ell drill dig and research it into oblivion. I've very often ended up playing that role in the team I was with and never for a second felt I was playing second fiddle to the rest. And they certainly were quite happy knowing my work made them all 20-30% more efficient in their work. – Newtopian Dec 07 '17 at 14:56
  • 1
    @Newtopian I don't like the idea that you consider such work to be a "support" position. I would imagine a support position more to do with mundane and boring tasks. – Euphoric Dec 07 '17 at 15:13
  • @Euphoric: You seem to attach an overly negative emotional response to the "support" part. Don't worry though you are not the only one but it is in fact support, this work aims to support the production of the actual product/software. Support is a lot more than responding canned phrases over the phone to frustrated customers. My customers are sitting all around me, using my products in their daily work. And yes, they do complain, and yes my job is to listen to them, big difference though... I can actually DO something about it and they know it making the conversation much more productive. – Newtopian Dec 07 '17 at 15:43

11 Answers11

107

"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... :-}

Bob Jarvis - Слава Україні
  • 1,665
  • 1
  • 9
  • 12
  • 21
    If anyone reading this has the 20th Anniversary edition of the book, it is worth reading the new preface and the new chapter 19. While even the 20th anniversary edition is over 20 years old as of 2017, the author points out several of the assertions in this answer which are often overlooked in the rush to summarize the whole book as "adding engineers to an already-late project makes it even more late." –  Aug 07 '17 at 13:44
  • 3
    What in the world does "UUGE" mean? Great answer, by the way. – Wayne Conrad Aug 08 '17 at 15:47
  • 6
    @WayneConrad vernacular for [huge](https://www.youtube.com/watch?v=DXRaboSo70A). – zzzzBov Aug 08 '17 at 16:05
  • UUGE is also spelled as YUGE, as used by Donald Trump :-) – Peter M. - stands for Monica Aug 09 '17 at 16:28
  • 2
    Having *been* an IBM systems programmer during that period, it was common to have very tightly defined roles in the team,with a specialty in a particular part of the OS. The person in each of those roles would be expected to know or learn everything there was to know about it, and act as support staff to any of the other experts. We essentially ended up with a surgical team per member of the staff, each with their own specialty. – Joe McMahon Aug 10 '17 at 00:27
  • Ah, the good old days - when every IBM computer leased came with source code for the operating system *AND* an on-site IBM support engineer to keep the dang thing running. They may not have been the *best* computers, but support..? IBM beat everyone else, hands down. – Bob Jarvis - Слава Україні Aug 10 '17 at 03:16
  • 1
    In response to your comment about making the same errors over and over, the Wikipedia article for the book has a quote from the author you might like: The tendency for managers to repeat such errors in project development led Brooks to quip that his book is called "The Bible of Software Engineering", because "everybody quotes it, some people read it, and a few people go by it". – Ryan Jul 22 '19 at 21:43
  • "...and a few people go by it" - and more than a few people do the opposite **because they're so much smarter!!!** (They're the same people that don't normalize a relational database, that don't use structured programming techniques, etc) – Bob Jarvis - Слава Україні Jul 22 '19 at 22:27
87

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.

Jörg W Mittag
  • 101,921
  • 24
  • 218
  • 318
  • 1
    Regarding the second to last paragraph, I think the surgeon was expected to work with pen and paper and the clerk would have been the one team member with access to the computer. – Bart van Ingen Schenau Aug 06 '17 at 18:18
  • 16
    'can you really imagine paying a full-time employee to print out source code, and manually index and file it?' No, but I can definitely imagine paying a full-time employee to manage version control and continuous build systems, and in fact in any medium-sized or bigger company this is the norm. In fact, managing wikis, document management systems and such is an entirely separate, even bigger role that there's usually an entire time of technical writers paid to do full time. – Miles Rout Aug 06 '17 at 22:53
  • 9
    "entire team would have one computer for themselves... was a stretch" - in the early 1980s orgs would have minicomputer + terminal-based systems, so while it was the same computer, users still would have had access to it on an equal basis and the ability to run their own programs (assuming decent user isolation and security existed). – Dai Aug 07 '17 at 04:33
  • I disagree on the last part of the answer. I think this has been implemented in Mob programming: they only have one computer and the whole team is working on the same task. The important difference is that you change the "surgeon" after a while, so no stop there. Check more details in my answer bellow. – Federico J. Aug 07 '17 at 15:10
  • 2
    While computers were expensive in 1975, keypunches were fairly cheap. When I first programmed mainframes (not in 75, but 77) we'd write out the code on paper, punch it onto cards, deliver it to a wicket and then check back periodically to see if the printout had been delivered back. (Turn around time could be 2 hours for us and at some sites more than a day.) A clerk would have been very handy for all but the first of these tasks. I didn't see terminals until 1979 or so. – Theodore Norvell Aug 08 '17 at 16:15
  • @Dai: I once saw a dev team where the only compiler on the entire floor was installed on a Win98 machine inside a secure locked room (complete with security guards) and programmers were expected to submit code changes to the architect in plain ASCII txt files plus documentation for why the change was needed. I pity those poor souls. – slebetman Aug 09 '17 at 09:56
  • @TheodoreNorvell: ...and we LIKED it that way!!! :-) – Bob Jarvis - Слава Україні Aug 09 '17 at 16:03
  • "Everybody is responsible for everything as a group" is semantically equivalent to "nobody is responsible for anything". – Bob Jarvis - Слава Україні Aug 09 '17 at 16:18
  • 1
    Re: Smalltalk - not only was every dev and every user supposed to have their own computer, those computers were also supposed to be *powerful* computers with *lots of memory* and a *GUI*. Think "workstation" rather than "PC". The original IBM PC's didn't have the horsepower to run Smalltalk. A dang shame, in my opinion... – Bob Jarvis - Слава Україні Aug 09 '17 at 16:20
20

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.")

Jon Watte
  • 317
  • 1
  • 4
  • 5
    I downvoted due to the absurd claim regarding rising cost of labour. Labour, even specialized engineering knowledge, is cheaper today than it was in 1969. Indeed the cost of labour being more expensive today underpins this entire answer and it is a false claim. – RibaldEddie Aug 06 '17 at 19:42
  • 2
    @RibaldEddie with respect to what? If you benchmark labor against the cost of living, it has been decreasing; an hour of work can get you more food/housing than it could in 1969 – k_g Aug 06 '17 at 19:58
  • 3
    @k_g well it does depend on location. In terms of inflation, in most places in the US, you can hire a developer for less in inflation-adjusted dollars today than in 1969. For reference, in the book Brooks suggests 20k for what today we would consider to be a senior dev architect and 10k for a run of the mill programmer that does the bulk of the work. In today's dollars, that 10k is about 65k. Today having most of the devs on your team earning 65k is a very good price. – RibaldEddie Aug 06 '17 at 20:23
  • https://i-cbc-ca.cdn.ampproject.org/ii/w1200/s/i.cbc.ca/1.4227440.1501287977!/fileImage/httpImage/image.png_gen/derivatives/original_620/cbre-research-tech-talent.png – RibaldEddie Aug 06 '17 at 21:09
  • 3
    This, essentially, software salaries are unchanged from 1969. Given inflation overall and the higher cost of living, developers are significantly cheaper today. – RibaldEddie Aug 06 '17 at 21:11
  • 11
    Indeed all of the benefits of the modern economic environment in terms of productivity and cheaper labour has all gone to the executive and shareholder class in business. As I said, even adjusted for inflation, software developer salaries have stayed the same while executive compensation has increased many hundreds of times higher than inflation. Additionally, many places, particularly along the west coast of North America, costs of living have increased significantly faster than inflation (see real estate) and yet professional developer salaries have barely kept pace with inflation. – RibaldEddie Aug 06 '17 at 21:33
  • 1
    Thing is, the number of *actually competent* software developers hasn't changed. Ubiquitous undergraduate education has lowered the standards for passing, but not the standards to actually be any good. It's merely created a whole lot of C grade students that then never get a job in software because they're not actually good enough. I got a C in a course *once*, and I would never ever hire me to do a job related to that area, as someone that got a C in it is utterly unprepared to do so. Someone that got Cs across their whole degree? No way anyone is hiring them. – Miles Rout Aug 06 '17 at 22:55
  • 1
    @MilesRout - two things to note: 1) *competent developers* are a rare commodity, as you note, but that doesn't reduce demand, and thus many other-than-competent people get hired to fill developer slots. Similarly, people are hired for reasons other than competence. :-( And 2) grades do not equate to performance. [Read this classic article](https://imranontech.com/2007/01/24/using-fizzbuzz-to-find-developers-who-grok-coding/), ye Mighty, and Despair! – Bob Jarvis - Слава Україні Aug 07 '17 at 11:33
  • 1
    Did anyone of you actually look up "the cost disease of the service sector" before you started down-voting? Also: Why else do you think secretaries are a thing of the past these days? The labor that is more expensive (relatively speaking, see above) is the "support labor" for engineers. My argument is that you don't get enough boost out of the support to make it economically worth it. – Jon Watte Aug 07 '17 at 20:59
  • 1
    @JonWatte Because computers are better. And secretaries aren't a thing of the past at all, by the way. – Miles Rout Aug 08 '17 at 04:35
  • 1
    So, if the capabilities of computers go up, then the relative value of secretaries (support staff) go down, and thus we get fewer secretaries (support staff.) Which is exactly my argument: Less support staff, because of technological development and relative values. – Jon Watte Aug 08 '17 at 22:35
  • 1
    @RibaldEddie Think in terms of years of salary required to buy a home. In 1970, the median cost for a home was about $23k. So two years of a developer's salary or so could buy a home. Today's median home cost is over $300k, so it would take about five years of that $65k salary to buy a home. – barbecue Aug 10 '17 at 01:36
14

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

Federico J.
  • 279
  • 1
  • 6
  • That quote is basically what I was thinking: It sounds like pair programming, where the "surgeon" is what we've called the "driver", except on a different scale. – Izkata Aug 07 '17 at 03:49
  • 7
    It seems to me this would require that extroverted people-oriented competent software developers. Best of luck with that. – Bob Jarvis - Слава Україні Aug 07 '17 at 11:41
  • Came here to say this; or various forms of team self organisation. – Marcin Aug 07 '17 at 20:26
  • 3
    @BobJarvis I disagree. I've had great success working in teams of introverts (and I think some that included extroverts too). The key is creating a space where people feel safe and open to contribute, and are willing to stretch their natural inclinations for a time for the benefit of the group. Susan Cain's Quiet was a huge help in understanding how to work well with different temperaments: https://www.ted.com/talks/susan_cain_the_power_of_introverts – David Carboni Aug 09 '17 at 13:15
13

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.

Matt Everson
  • 239
  • 1
  • 3
11

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.

RibaldEddie
  • 3,168
  • 1
  • 15
  • 17
  • 1
    so basically, nothing happened to it. + – gordy Aug 06 '17 at 22:02
  • 1
    @gordy yes and no. You'll notice that in the Brook's example, in all likelihood it would be up to the managers to determine who was in each role on the team, but in a modern agile concept, the team is self-organising. So the roles of surgeon or co-pilot fall out naturally from the way the team works. I think that's a key difference: self-organising vs. company-dictated. – RibaldEddie Aug 06 '17 at 23:26
  • I'd change "most" to "some". It really depends on the team dynamics. And it definitely has to grow organically if a surgeon is dictated from above the outcome will be suboptimal so +1 for self organized. – Peter Aug 07 '17 at 14:03
  • 2
    *Sayings from The Tao of Software: #IV - The Tao of Teamwork:* **Good software is written by small teams working fast. Bad software is written by large teams working slowly.** Corollaries: - The optimal size of a team is 1; - The maximum practical value for team size is 3; - For team sizes > 3, (mis)communication becomes a serious issue; - For team size > 6, project completion becomes seriously compromised. Project completion on deadline is likely out the window. In cases such as this the smarter developers will use the door... *Thus it is written...* (**BWOOoooonnnggggg!!!**) – Bob Jarvis - Слава Україні Aug 08 '17 at 17:52
6

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.

Charles Merriam
  • 419
  • 3
  • 5
  • 9
    The part that makes me smile (?) is the "...multiple managers..." thing. One manager is more than sufficient to reduce productivity. Multiple managers might drive developers to thoughts of either suicide (introverts) or murder (extroverts). – Bob Jarvis - Слава Україні Aug 07 '17 at 11:41
  • 4
    @BobJarvis -- I have had, depending on the project, as many as five simultaneous "managers" with varying titles. The effect is pretty much as you'd imagine. – Rob Crawford Aug 07 '17 at 14:03
  • 1
    Obviously you're an extrovert. So...insanity defense? Mexico? Or...justfiable homicide..? :-) – Bob Jarvis - Слава Україні Aug 08 '17 at 17:56
  • So that's why I had five bosses at one company. While I was there, any problem, whether it was mine or someone else's, I would hear it from 5 different perspectives. I usually had it analyzed by the time number 2 came along and it was just annoying to hear about it there more times. – Robert Baron Aug 09 '17 at 11:29
  • The original idea was not "have five different managers trying to interfere" but provide, for example, "an HR benefits person" and "an HR career development person" etc. I think multiple managers would work if you billed each manager's department based on how often they contacted the engineer. Would make a fun video game! – Charles Merriam Aug 25 '17 at 21:46
2

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
Gaurav
  • 567
  • 5
  • 14
1

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.

JeffO
  • 36,816
  • 2
  • 57
  • 124
0

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).

Mike Ounsworth
  • 117
  • 2
  • 2
    That's definitely not the DevOps model. – RibaldEddie Aug 06 '17 at 18:27
  • 5
    In fact DevOps is more like the surgical team model because Developer Operations implies that operations exists in service to development. DevOps is about two core concepts: that operations should be seen as a development practice and therefore that the tools and techniques used in development, like source control and agile methods of management, should be used by operations and that operations is there to support development. – RibaldEddie Aug 06 '17 at 18:30
  • 1
    @RibaldEddie Interesting. My experience with the DevOps group at my company is that they only hire developers and they are responsible for everything from product development, testing, documentation, deployment, etc. The word "cross-functional" comes to mind. Oh well, with 2 downvotes and a delete vote inside 15 minutes, I guess I'll be staying away from this site. – Mike Ounsworth Aug 06 '17 at 18:35
  • Right. You said it right there. The operations teams hire developers. Operations is a development practice to be done by software developers. That's not how it used to be the conventional wisdom. Operations used to be tech-support style sysadmins and technicians. Today the skills needed to be a DevOps sysadmins are very similar to the skills needed to be a software engineer. – RibaldEddie Aug 06 '17 at 18:39
  • As to cross-functional / single team environments, that is also very much in fashion because of cloud services like AWS that alleviate a lot of the burden that used to fall on to ops teams. So to integrate the ops tasks directly into the development team that works on the product is feasible. But eventually you might get big enough to require dedicated ops developers. – RibaldEddie Aug 06 '17 at 18:41
  • With you so far, so why the downvotes? Everything you've said seem to agree with what I wrote that cross-functional DevOps teams are the antithesis to the surgical team model. I'm clearly missing something. – Mike Ounsworth Aug 06 '17 at 18:44
  • They are not. Go back and read the surgical model from the book. Cross functional team is exactly what the model describes. A cross functional team is not a team where every dev does everything, it's where every dev who may be a specialist on their area _is on the same team_. – RibaldEddie Aug 06 '17 at 18:46
  • A cross functional team is one where the QA dev and the ops dev is on the same team as the front end UX dev and the back end service dev. It's one team. The surgical model is one team. Even in a cross functional team there will be leadership emerging. The surgeon will emerge, the co-pilot, etc. – RibaldEddie Aug 06 '17 at 18:48
  • 1
    Ah, then we have different definition of "cross-functional". I'm using it to mean that every member of the team is capable of doing every task - Jiras routinely get thrown around between people because they have done away with specialization. Someone who is developing this feature will test or document the next feature. That is the "DevOps" that I have experienced. – Mike Ounsworth Aug 06 '17 at 18:48
  • that would be a very ideal case, and while it's a worthwhile goal, in practice some people will be specialists in some areas. As the surgical model implies, the more senior generalist developers are likely to self-organize into the surgeon / co-pilot roles. – RibaldEddie Aug 06 '17 at 18:50
  • Still with you, and still not understanding the downvotes. Oh well. – Mike Ounsworth Aug 06 '17 at 18:51
  • Because the surgical model has the concept of the surgeon and copilot and you've left that out of your answer. There has to be Those roles in order to make it work like that model. Where do those fit in? – RibaldEddie Aug 06 '17 at 18:54
  • I don't care much about labels (DevOps, surgeon, whatever) but the only truly workable approach to training up a group is to have people who *first* become fully competent at their own specialized role (with a general understanding of each other role and how it fits in the group's activity), and *then* expand their competence to learn other specialized "hats" around them. In other words, you must do *one thing* well before you can learn to do everything. And the "one thing" to start with is what you actually *do* in your role. – Wildcard Aug 08 '17 at 00:22
  • 1
    @MikeOunsworth: that's a team of cross-functionals :-D – Jörg W Mittag Aug 08 '17 at 20:16
  • Don't get discouraged by down votes. But keep in mind that it is a question/answer site, not an opinion site. – Theodore Norvell Aug 08 '17 at 20:19
  • 1
    @TheodoreNorvell Thanks for the encouragement. Though I'll point out that I'm 22k rep on security.SE, so it's not like I'm new to the SE format. I do find that there are pretty big gaps between what what the community finds acceptable from one stack to another. – Mike Ounsworth Aug 08 '17 at 20:26
0

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.

Newtopian
  • 7,201
  • 3
  • 35
  • 52