Xref: utzoo comp.lang.eiffel:1333 comp.object:2430
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!jarthur!ucivax!orion.oac.uci.edu!ucsd!pacbell.com!pacbell!osc!tma
From: tma@osc.COM (Tim Atkins)
Newsgroups: comp.lang.eiffel,comp.object
Subject: Re: Managing multi-programmer projects in OOP.
Message-ID: <4171@osc.COM>
Date: 25 Jan 91 08:04:36 GMT
References: <2603@trlluna.trl.oz>
Reply-To: tma@osc.UUCP (Tim Atkins)
Followup-To: comp.lang.eiffel
Organization: Versant Object Technology, Menlo Park, CA
Lines: 34

I'll briefly throw my two cents in here.  The interesting and difficult
part of multi-programmer OOP is precisely the part that is not logically
divisible into independent projects.  I recommend placement of the
strongest design talents on the design of this common base of classes.
Those portions of the system that are independent can proceed by whatever
schedule and amount of up-front analysis/design is amenable.  All using
groups must have input as to what they need of the commonly used set
of abstractions though.  As in normal development, agreement as to inter-
face is the paramount consideration.  Once this has been agreed the actual
developers of this critical layer are much freer using OO to change the
actual architecture as long as the interface is preserved.

I have some difficulty believing that too much analysis is called for,
particularly in OOP.  Just enough to identify common problems and abstract
out the essential portions seems to be right.  To do this well places a 
high premium on more than one individual having a good working knowledge
of the entire design.  One such individual is crucial to the coherency
of the system.  Two or more are likely to make it a much cleaner design
as they will catch each other's oversights.  Perhaps the most difficult
part of OO is that it is much more essential than in more traditional 
approaches that ALL team members are aware of the classes and their methods
as only such awareness can drive the tightness of the design and the
achieving of maximum reuseability.  Such awareness must be tightly 
separated from issues of responsibility if the project is not to 
bog down in endless committee reviews.  

As a long time designer and implementer I am also highly aware of the
fact that a paper design is next to worthless as a specification compared
to at least a skeleton of working code.  The really subtle at design time
is glaringly obvious once a bit of code is actually written.  I would 
strongly recommend a technique of lots of early prototyping and an 
incremental development strategy.

- Tim Atkins