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

[dmg@ssc-vax (David M Geary)]

]> Who knows?
] Jim Showalter

]>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.
]
]I may be misunderstanding your post, but from what I'm able to glean from
]it, you don't think hierarchical decision making works on a project, and
]that the alternative is a sort of enlightened egalitarianism. If so, I
]disagree, based on my own experience. One does not expect bricklayers,
]welders, pipefitters, etc to also design a skyscraper, any more than one
]expects an architect to wire the offices. This always seems to get cast
]
]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?

  I believe that the ones writing the actual code should be the ones
  that *architect the code they are writing*.

  We have GUI, client, and server software for accessing
  (ultimately), Oracle over a network.  We have 3 main guys
  responsible for GUI, client, and server respectively.  Each
  developer designs (architects, if you will) his respective system
  (GUI, client, or server).  Each developer writes the code to
  implement the design.  Each developer also has a "sidekick" who
  understands the system, and helps out from time to time writing
  functions, porting code, etc.

  Of course, there is data constantly flowing between the GUI,
  client and server.  Therefore, architectural decisions concerning
  interfaces between the 3 systems are decided by committee.

  I like the idea of having a small group (possibly 1) of developers
  responsible for a small subsystem.  The requirements for the
  subsystem are decided by implementors.  The design and coding for
  the subsystem are totally up to the group of developers.  When the
  subsystems interact, the issues are decided upon via committee,
  with those directly responsible for the subsystems which have to
  interact having the ultimate say in the design decision.

  To me, this falls in line with OOP mentality.  When one writes
  modular, reusable code, a class is defined with a specific
  interface.  For instance one may have a class point, with an
  interface consisting of point_Create(), point_Destroy(),
  point_GetX(), point_GetY(), point_Move(), etc.  How the point
  class *implements* this interface is nobody's business but the
  author of the class.  The same thing can be applied to subsystems
  in a software system.

  In summary, then:

  1. Break the system down into subsystems.

  2. Assign small teams to each subsystem.

  3. Teams are responsible for design/development of subsystem.

  4 .Interfaces between subsystems are designed by the developers of
     the subsystems involved.

  Now, it may be that in a very large project, there are so many
  subsystems that those dealing with the subsystems at the bottom
  cannot see the light of day.  In such a case, one may have system
  architects who *work with* the developers of the subsystems, to
  help design interaction between the subsystems.

  However, to have one group design, and then hand the entire design
  over to a group of "coders", I think, is asking for trouble.
  Communication alone between the designers and the coders leaves
  enough room for error to make me mighty nervous.

-- 
|~~~~~~~~~~       David Geary, Boeing Aerospace, Seattle, WA.       ~~~~~~~~~~|
|-----------------------------------------------------------------------------|
|~~~~~~  Seattle:  America's most attractive city... to the *jetstream* ~~~~~~|
|-----------------------------------------------------------------------------|