Louisa Rosenheck - lrosenhe
Mythical Man Month Response Paper
February 19, 2003

	In chapter 4 of The Mythical Man Month, Brooks discusses the trade-offs
involved in organizing a software development team as an 
"aristocracy," that is to have an "elite" group of architects dictating
what the design will be, or to have a "democracy," in which the members of
the team, architects and coders alike, all have equal say in the design of
the system. From my experience in this class so far, I can see that this
is a crucial descision in the organization of a project and its
team. While I was writing both my requirements and specifications
documents, I found that my ideas for functionality and implementation were
very interconnected and at times a little muddled, and that my priorities
were easily confused with considerations about what would be difficult to
implement and integrate with other parts of the project. Especially while
writing the specifications, it was easy to get sidetracked in thinking
about what functionality would be better for the users and what was better
for coding and lower level design. I saw myself spending a good deal of
time on these considerations, and so I can easily imagine that discussing
and making these sorts of decisions together in a large project group
would waste time and be frustrating and likely even impossible.
	Looking ahead to the design and coding phases of our projects, it
is obvious that we don't want to get bogged down in extraneous
debating. Therefore, Brooks's theory on the merits of the aristocracy
model makes it seem much more practical and efficient. In many fields,
division of labor has been found to be the most efficient way of
organizing a group, because that way the members of each subgroup can be
experts at their task and they will be more focused and
efficient. Likewise, in a software system, if the responsibilities are
divided clearly, the members of each subgroup will be able to concentrate
on their own goal, for the architects what the program should do, and for
the implementers how it should be done. This way, the system will be able
to preserve its conceptual integrity, accomplishing what it is really
meant to do, with a smoother process and a more useful product.