From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: ** X-Spam-Status: No, score=2.6 required=5.0 tests=BAYES_20,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!menudo.uh.edu!buster!brain!chuck From: chuck@brain.UUCP (Chuck Shotton) Newsgroups: comp.lang.ada Subject: Re: chief programmer team organizations was (c++ vs ada results) Date: Wed, 26 Jun 91 00:19:44 CDT Organization: BIAP Systems Message-ID: Reply-To: chuck@brain.uucp X-Mailer: uAccess - Mac Release: 1.5 List-Id: 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