awhull essay
	
	The Mythical Man Month's focus on the conceptual integrity of a program's
design brings up some important points, but ultimately it fails to fully
address the problems associated with achieving them.  In it, Brooks presents
three questions commonly brought against his recommendation of an aristocracy.
The questions are indeed valid, but while reading I was struck with the
inadequacy with which Brooks combats the claims.

	The first critique given is that of the architects forming a new
"intellectual elite, set up to tell the poor dumb implementers what to do."
Brooks defends this, stating, "If a system is to have conceptual integrity,
someone must control the concepts.  That is aristocracy that needs no apology."
However, in his own mocking description of the complaint, he describes the
implementers as "poor" and "dumb" for a reason.  This is indeed the way the
architect can begin to feel about the implementers; as well as treat them.
Surely there is a way to have someone overlook the agreed upon conceptual
integrity, rather than demand their own.  It is naive to think that one person
is even fit to oversee the grand design, or (in an obvious position of power
over the implementers) show restraint in forcing their own ideas.  A raging
despot is sure to spoil any excitement implementers have on a project, and this
seems to be the kind of leadership that Brooks supports.  The complete faith!
in the designer also assumes he is the best for the job.  If he is not, and no
checks or balances in place, the entire project can rest on their very fallible
shoulders.  An apology is always needed when taking away from the freedoms of
the very capable implementers.  They should be told, at the least, why they are
not permitted to have input.  

	Brooks' second quandary is that "Has not all the creative work been
sequestered for this elite, leaving the implementers as cogs in the machine?"
He arrogantly proclaims this is not an issue at all!  He states that there is
just as much creativity in the implementation of the project, and that the
implementers should be satisfied with their situation.  This is just ignorant.
From my own experience in working with projects, the most enjoyable part of
creation is the dreaming up of what you are making, and what you will include.
Every person has their own pet features they would like to see in the project,
or ideas they think are worthwhile.  This is where the ideas are documented,
and planning begins.  An apt analogy is the architect who designs the building.
He is free to explore many options at his fancy and create from his mind.  The
construction worker on the other hand, has his "creativity" limited to simply
selecting materials and following a plan.  Hardly creative!  at all!  The
passion is imbued in the design, and the implementation is a labor of this
love.  A labor of the architect's love is not something most implementers are
able to whole-heartedly embrace. Even if this was not the case, the mere
perception that the architect has more creative control becomes the reality.
Thus even more apologies are needed.  There is a reason that most game
programmers strive to become game designers.  They want to make their own
vision, not someone else's dream.

	Brooks' last point endorses ignoring feature ideas from implementers or
users.  This seems extremely foolish.  He is once again placing a sort of
special power with the architect.  His features will be included, because they
were included with his original design, while other better ideas could be
thrown out.  It is then imperative that his design accommodates the most and
best set of features.  It also alienates the rest of the team, whose opinions
are then not as important.  It would seem that some sort of group consensus on
features should be done before the design is completed.

	Throughout, Brooks seems to be targeting the book to the "leaders" of
projects.  His tone is very commanding, and he seems to ignore the
implementers, in favor of an "elite" group.  The problem is that members of
this particular group can be largely self-elected, and they cannot handle the
responsibility and power suggested by Brooks.  From my own experience, while
one person should be in charge of making sure the design is coherent and
workable, all members should have input, as it keeps the team excited about the
project and working at maximum productivity.  This more than makes up for any
small problems caused with the design.  Especially in a situation such as our
class, where everyone sees the others as peers, an aristocracy seems largely
unworkable.