Author: Mark Humphrey <msh>
Class: CS190
Assignment: "Mythical Man-Month" Response
Date: 2/19/2003

While the age of the essays written by Brooks sometimes seems to hinder the point
which he is trying to get across, I found that his concept of the "Surgical
Team" was still an interesting and meaningful topic. In this essay Brooks
discusses how there has been shown to be a dramatic difference in productivity,
as much as a 10:1 ratio, between even experienced programmers. He goes on to
talk about his early aruguments in which he has demonstrated that as a project
team grows bigger, so to does the costs imposed by communication or lack
thereof.  Putting these two pieces of information together he suggests that
perhaps it would be best if only the best programmers worked on the project and
everyone else was fired, reducing the levels of management and necessary
communication and working with a small "sharp" team. The issue with this
approach which he immediatetly points out is that it fails for the truly large
programs which will take far to long to complete even with the remaining core of
elite programmers working on it.

To address this problem he then discusses a proposal made by Harlan Mills. The
idea is that each part of a a project should be tackled by a team organized
like a "surgical team" rather than a "hog-butchering" team. What this means is
that each team should actually only have one or two members, the most
experienced and productive programmers, working on the problem while the rest 
of the team supports them, as opposed to the entire team "cutting away at the
problem." The advantage here is that the the design and implementation of the 
project will be the sole creation of one or two minds, keeping the integrity 
which would be lost if each individiual on the team contributed his or her own 
creativity to the problem. The ideal size of this sort of team would be about 
ten people, neccessitating that several "surgical teams" be used for large projects. 
When this idea is scaled up it still has advantages as it reduces the amount 
interfacing and communication needed.

While this is an interesting concept, I don't think that it would be a good idea
to have one student in our group of ten do all then programming. Our situation
is somewhat unique in that the timeframe for doing this project is severly
limited. In addition, there is much less support required of this project than
the typical commercial application. 

However, from my limited group experiences in cs32 I can see how the "surgical
team" approach can be very effective. While I spent considerable time coding,
almost as much time was spent making sure that the interfaces of the members of
my group matched up, and dealing with makefiles, cvs, permissions, and creating
graphics and documentation. Much of this time could have been reduced if the
project was the sole creation of one individual, with the other team members in
supporting roles. The issues which arise when a project is the result of the
work of several different minds could be easily seen in the struggles of many
of the five person groups, who sometimes had great difficulty implementing what
seemed to be much smaller projects than the one which our three person team worked
on. At the time this was a big surprise as in my inexperience I felt that our
groups was at a disadvantage by having two less members than many other teams.

Overall I can see much merit in the "surgical teams" idea, however, at the same
time I can see how the obvious temptation to put the entire team to work
designing and coding often wins out.