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_40,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.lang.ada:5824 comp.lang.c++:14358 Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!nuchat!buster!brain!chuck From: chuck@brain.UUCP (Chuck Shotton) Newsgroups: comp.lang.ada,comp.lang.c++ Subject: Re: chief programmer team organizations was (c++ vs ada results) Message-ID: Date: 24 Jun 91 23:59:06 GMT Reply-To: chuck@brain.uucp Organization: BIAP Systems X-Mailer: uAccess - Mac Release: 1.5 List-Id: In article <1107.286584f0@vger.nsu.edu>, g_harrison@vger.nsu.edu (George C. Harrison, Norfolk State University) writes: > Do chief programmer teams really work anywhere outside of a university > classroom or in an experimental industrial setting? > > Approaches to running large scale development efforts appear to run the full spectrum from totally autonomous hacker collectives to dictatorial chief programmer authoritarian states. From practical experience, I can relate you a few success stories on some MEDIUM-sized (20-50 member teams) development efforts. An approach that seems to work well (with Ada) on data and user oriented application code tasks is this. First, and foremost, all members of the development team need to feel that they can make a constructive contribution to the DESIGN as well as the more mundane coding effort. This has the effect of getting everyone "signed up" to the grand vision of the system. All the programmers, designers, and systems engineers have some stake in the quality of the final product, because they are allowed to participate throughout the entire life cycle. The concept of an "elite" design team dictating system architectures to a "serf" class of coders is offensive to all but the most uncreative of Ada programmers. Before I get flamed to death, let me point out that on the tasks I've managed, programmed on, or designed, it was VERY important for management to be fully aware of the individual talents of each programmer. Then, structure the team in such a way that each (productive) member of the team can make a constructive contribution to the level of their abilities. Practical experience has also shown that most managers don't show the slightest inclination towards doing this. On the SSE project, our most successful development efforts involved teams of designer/developers who had cradle to grave involvement with the software's life cycle. Every task that got in trouble or resulted in a less than optimal solution was characterized by a few individuals mandating design decisions on a staff of talented (and ultimately, resentful) developers. These "problem" tasks also had serious trouble achieving a common vision of the final system. The moral of the story seems to be: Where practical, allow the greatest possible involvement in analysis and design activities by the people who are ultimately going to code the system. Not only is everyone "signed up" to the vision, but you end up educating a bunch of developers to be something more than code slaves in a body shop. [I have NO idea what this message has to do with comp.lang.ada, other than the fact that all of this "experience" was gleaned from Ada development tasks.] ----------------------------------------------------------------------- Chuck Shotton Internet: cshotton@girch1.med.uth.tmc.edu UUCP: ...!buster!brain!chuck "Your silly quote here." AppleLink: D1683 MacNet: shotton