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

[chuck@brain.UUCP (Chuck Shotton)]

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