
Books chapter three - vog
https://www.tedunangst.com/flak/post/books-chapter-three
======
vog
When reading this summary of "The Mythical Man Month":

 _> The best way to do that is to organize the team like surgical units. In an
operating room, there’s a large group of support staff, but only one surgeon.
One person cuts, not ten. A programming team then has only one programmer, but
many other support stuff._

I instantly remembered what I thought when I read the book myself: Why isn't
that taught at university? Or mentioned in any other software engineering
book?

Many other parts of "The Mythical Man Month" are often cited, but the
"Surgical Team" chapter is almost never cited.

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
Thanks to a3n and dllthomas for your attempts to explain this. I realized that
my question is better suited for SE than for HN:

[https://softwareengineering.stackexchange.com/q/355203/69228](https://softwareengineering.stackexchange.com/q/355203/69228)

~~~
dllthomas
Honestly, I think this setting will get better responses (if it actually gets
responses...)

------
a3n
> Why isn't that taught at university? Or mentioned in any other software
> engineering book?

Because no one goes to school to learn to be a programmer so that they can not
be a programmer.

~~~
dllthomas
I don't know. Maybe it'll work, maybe it won't, but detractions I've seen seem
to mischaracterize the proposal in ways that undermine it. Your complaint here
seems an example of (or derived from) that. (Though of course I assume it's a
difference of interpretation and/or misreading by one or more of us, rather
than any malfeasance!)

First, as a bit of an aside, it's not strictly true that "no one goes to
school to learn to be a programmer so that they can not be a programmer." Some
people go to school to learn to be a programmer so they can manage
programmers. Further, some people go to school to learn to be a programmer,
then find there's something other than programming that they'd rather be doing
instead. And of course some programmers didn't go to school at all.

All of that said, I take your general complaint to be about the roles other
than "surgeon" essentially requiring programmers who are essentially not
programming?

I think that's not really the case, as the concept was intended. Many of the
roles on the "surgical team" are still programming. Those that genuinely
aren't can be filled by people trained specifically for the role.

Additionally, some of the roles are likely to rotate project to project. A co-
pilot one project might handle tooling the next. All roles call for competent
people, and a variety of perspectives is likely to be a boon.

~~~

Examining the roles in turn, as to "is it programming?" and "does it require a
programmer?":

"The surgeon" \- Obviously this is principally a programming role, although it
does include managing documentation. As that's often presently part of a
programmer's role, I don't expect this is your complaint - if it is, state it
more clearly and I'll address it.

"The copilot" \- Ted implies this is not "really" a programming role. I
disagree. In addition to what sounds like pair programming and/or code review,
and coordination with other teams, we find in the TMM description: _" He
researches alternative design strategies[,]"_ which is likely to involve
prototyping, and _" He may even write code, but he is not responsible for any
part of the code."_ It is true that the role is probably less actual coding
than being the surgeon, but doesn't sound like less than some programming
roles in industry today.

"The administrator" \- This is clearly not a programming role, but equally
clearly doesn't require someone trained in programming. The same is true of
the secretaries and the program clerk, with a note that much of the workload
in these roles can be dramatically reduced by automation (Git + Travis seems
to be 70% of "the clerk") and in many cases these roles can probably be shared
by one or two people.

"The toolsmith." This clearly benefits from a programming background. Whether
it's a programming role seems to depend on context. Certainly, rolling custom
editors isn't likely to still be a thing. Massaging an editor plugin might be
(and with fewer people working directly on the code, targeting their
environment is maybe more tractable). Tools for interacting smoothly with any
custom data formats (or any additional semantics on top of standard data
formats). I could see this easily extending to "I need a library that does X"
\- from Brooks: _" The tool-builder will often construct specialized
utilities, catalogued procedures, macro libraries."_ \- although that may
overlap with "the co-pilot".

"The tester" \- people wanting to code winding up in testing is already a
thing that happens. That said, there's actually quite a lot of coding that can
be done here, especially moving into generative testing. I'd also consider, on
smaller projects, collapsing "the editor" in here, with an eye to assuring the
test suite keeps the docs honest.

And lastly, "The language lawyer" is _all about_ the code - probably more so
than "the surgeon", who has some additional responsibilities. This is a role
for experimentation and demonstration. _" The language lawyer can find a neat
and efficient way to use the language to do difficult, obscure, or tricky
things. Often he will need to do small studies (two or three days) on good
technique."_

