Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!cbmvax!kevin
From: kevin@cbmvax.commodore.com (Kevin Klop)
Newsgroups: comp.lang.c++
Subject: Re: chief programmer team organizations was (c++ vs ada results)
Message-ID: <22786@cbmvax.commodore.com>
Date: 28 Jun 91 19:26:47 GMT
Reply-To: kevin@cbmvax.UUCP (Kevin Klop)
Distribution: comp
Organization: Commodore Technology, West Chester, PA
Lines: 119


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

While I agree thgat the internal implementation of the sub module
should be left up to the implementors, I disagree that they should
be the ones to decide the external interface that the sub module
presents to the world.

Someone has to provide a cohesive view of the interfaces or else
no sub module will be able to talk to any other sub module.  It's
this flow of information, or definition of interfaces, that I think
of as architecting a design.

>
>  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.

Aha!  here's where all of a sudden, we're back in agreement.  Your
three guys are acting as the systems architects as well as architecting
their own committee.  While I feel that someone has to architect the
overall system, that does not preclude that the overall architects
aren't also the people that implement and/or architect subsystems
as well.

>
>  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.

Correct - but that's part of the architect's job - defining sub-systems
and their interactions/interfaces.

>
>  2. Assign small teams to each subsystem.
>
>  3. Teams are responsible for design/development of subsystem.

Within the guidelines of the system architecture.

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

Nope - part of deciding what are subsystems is also deciding how they
interact/interface.  This should be BEFORE the subsystems have had
people assigned to implement them.

>
>  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.
>

The way I see it is a hierarchical series of architects.  A couple of
people that take the problem and define some modules and interfaces
between the modules.  Then, these modules, along with the interface
definitions, are handed to module architects which define modules within
the module, and define how they interact.  These modules are handed to
programmers who realize the design in computer code.   Note that nowhere
does this state that the programmers implementing the code aren't also
the people architecting the "next higher level" as well.

>  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.
>
>

Remember that OOP is NOT a design philosophy, it's an implementation
methodology.  While one can design in such a way as to make OOP easier,
a design doesn't HAVE to have any knowledge of the implementation
methodology, much like algorithms don't care what language they're
implemented in.

Design philosophies tend to fall into "Top-down", "Bottom-up", or the
vastly popular, "Inside out" (wherein the code starts somewhere in the
middle between top and bottom and then grows in both directions).

Don't confuse design with implementation.

					-- Kevin --

Kevin Klop		{uunet|rutgers|amiga}!cbmvax!kevin
Commodore-Amiga, Inc.

	Ever feel like a lemming that's afraid of the water?

Disclaimer: _I_ don't know what I said, much less my employer.