Emma Boroson
CS190 
Mythical Man-Month reading


	In The Mythical Man-Month, Frederick Brooks emphasizes the
importance of delegating the tasks of a large programming project in a
manner that takes into account the people involved as well as the time
schedule to which the group must adhere.  The metaphor of the surgical
team, while not directly applicable to our class's projects, does give a
clear sense of the kinds of divisions that, presumably, must be made in
order to create some sense of order and efficiency in a large-scale
project.  It is the chapter titled "Aristocracy, Democracy, and System
Design" though that I find the most important to this class and this
project.  Achieving "conceptual integrity," as Brooks writes, inherently
involves two main concepts: providing function, and providing ease of use
and simplicity.  (Brooks clearly writes, "Neither function alone nor
simplicity alone defines a good design.")  And while these descriptions of
the outcome of the project are, no doubt, important, he claims that its
the design and the way the group goes about designing that will make or
break these desired results.
	I certainly agree that, speaking generally, it is often a better
idea to have one person or a small group of people ("aristocracy") make
and decide on these design decisions, and that certainly those people with
more experience and skill in design should fill this position, while those
more skilled in the art of programming should fill the chief programmer
("surgeon") position.  However when I first read this section, I
immediately wondered about fitting this into the schedule -- a point that
Brooks soon brought up later in the chapter -- how it is that time is not
wasted, if Architecture group A must design the entire project before
Coding group B even begins to start their work.  Brooks' response to this
is that "long before the external specifications are complete, the
implementer has plenty to do."  In my experience in CS32, I found that
this was not completely the case, or rather, that when this was the case,
it often lead to disaster.  In my final project group, the four of us
split up the coding tasks among us before we had fully thought out all the
specifications of our project -- a decision that we made consciously
(although without much meaning behind it).  So, between the semi-weekly
meetings we had at the start of the project's schedule, each of us began
work on our respective parts of the program, knowing that we shouldn't get
too deep into detail of our coding, as we hadn't yet figured out all the
interfaces and specifics.  We did this (started coding) because we felt
that doing otherwise would be a waste of time -- we knew we had a certain
amount of coding to get done, and that by starting earlier, we thought we
would be more efficient.  However, when we started flushing out the
specifics of our project and the details of our interfaces, we each found
that we had done a large quantity of unnecessary and unused work.  Not
only that, but that now presumably more time than would otherwise have
been necessary would be needed to FIX each of our parts of the code,
because, in the intention of saving time, each of us had ASSUMED
interfaces that, of course, did not end up being the actual interfaced
used.  
	In short, I agree with Brooks that the design and complete details
of interface should be thought up by an elite group of people, and that it
is important to delegate responsiblity in a way that best fits the design
requirements of the project.  However in scheduling the work of the
implementation, I don't think it is always possible to be so efficient
that everyone in the group is being utilized at one time -- sometimes, I
believe that working in parallel, while it may SEEM more efficient and
time savvy, may end up costing time in the end.