Re: chief programmer team organizations was (c++ vs ada results)

[chuck@brain.UUCP (Chuck Shotton)]

In article <1991Jun26.005625.25608@netcom.COM>, jls@netcom.COM (Jim Showalter) writes:
> If everyone tries to design the architecture, the result is not an
> architecture at all--it is a camel. Design by committee is generally
> regarded as a bad idea, yet you seem to be advocating a really big
> committee in your post. Or am I just confused?
> 
The point I was trying to make is that the concept of an Ada "coder" is antiquated.
Once upon a time, when designer could draw flow charts and make entries on
coding sheets, it was easy for the worker drones to turn that info into Cobol
or Fortran. A "coder" has clerical, mundane, non-creative connotations. Basically,
it's someone who takes someone else's ideas and turns them into syntactically
correct code. 

My point is that this concept of a few people PRESUMING to understand all
the intricacies of a system and mandating design decisions to a group of "coders"
is out of date. It's the "aerospace way," and is probably the single biggest
reason why there is a crisis in engineering and delivering large systems.

When working on "mega" systems (500K+ SLOCs), no handful of humans can keep
it all straight. I can't begin to count the number of times where Joe Coder
has had a totally novel idea that made huge differences in the architecture
as engineered by a few "Chief Programmers".

I'm not advocating design by committee by any stretch of the imagination.
Design by consensus, yes! My experience has shown that EVERY time there is
contention or disagreement during the design process, it is because of only
2 reasons. 1) Existing design Ideas are not being effectively communicated, 
or 2) Someone actually has a better idea. In the first case, I want to make
sure everyone on the team UNDERSTANDS the system, so I want everyone to have
input during the design process. This input is a measure of their level of
understanding. In the second case, I certainly don't want to overlook a better
approach by relegating a talented individual to a role of Ada coder.

I am certainly NOT advocationg a totally egalitarian approach to design and
implementation. That would presume that all designers/developers are equally
talented in all aspects of the job. I was very careful to point out that MANAGEMENT
must accept the responsibility for determining the level to which each individual
can contribute and allow them to do so.

This approach falls somewhere between "chief programmer" teams, and hacker
approaches to problem solving. The value lies in creating a team environment
where everyone is allowed to contribute in a constructive fashion to the design
and architecture of the final system. Notice I said "contribute." That doesn't
imply that all contributions are equally valid, nor must all contributions
be accomodated. It only implies that contributions must be allowed. Someone
must have the final decision as to what stays or goes.

Given that Ada lends itself well to decomposition that often follows the CSCI
decomposition of a system, it allows an organization to mirror the architecture
and people can contribute at the level they are comfortable with and responsible
for.

If people feel they are part of the process, you're more likely to receive
their maximum effort. The result being a quality product that is somewhat
better than "good enough." In an industry (DoD contracting) where there is
little to no incentive (eg. cost plus contracts) to do an on-time, above-average
job, every little bit helps.

This is sort of a religous subject, and it certainly has a lot to do with
management styles. I prefer to treat all individuals in a team environment as
equals until they prove otherwise. (This give MY managers major heartburn...)
Many people in this business see programmers as commodities to be tossed at
a problem (billing hours, all the while). These are the people that still
subscribe to the mythical man month. Type A, Theory X, call it what you will.
It manifests itself in all its glory on "Chief Programmer" tasks.

-----------------------------------------------------------------------
Chuck Shotton                 Internet:  cshotton@girch1.med.uth.tmc.edu
BIAP Systems                  UUCP:      ...!buster!brain!chuck
"Your silly quote here."      AppleLink: D1683       MacNet: shotton