Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!rpi!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!johnson
From: johnson@m.cs.uiuc.edu
Newsgroups: comp.lang.smalltalk
Subject: Re: OO Development Differences
Message-ID: <5600015@m.cs.uiuc.edu>
Date: 4 Dec 90 22:29:00 GMT
References: <23765@grebyn.com>
Lines: 50
Nf-ID: #R:grebyn.com:23765:m.cs.uiuc.edu:5600015:000:2624
Nf-From: m.cs.uiuc.edu!johnson    Dec  4 16:29:00 1990


One of the main reasons that people are attracted to OOP is reuse,
and managing for reuse is a lot different than managing traditional
software.

First, reuse doesn't happen by accident.  More particularly,
reusable software doesn't happen by accident.  Software that
was not designed to be reusable isn't.  Even if it was designed
to be reusable, it isn't reusable until it has been reused a
few times.

If you decide that you are not going to WRITE reusable software
but are only going to REUSE it then the impact of reuse will not
be that great.  You will need to schedule time for your people
to learn the software that you are going to reuse (don't think
that it will not take any time--it will!) and you might need to
assign someone to be the local expert on the package, but the
overall software process is not changed much.

However, if you are going to develop your own reusable software
then you will need a large change in your software process.
There needs to be a group of people (usually small) who are charged
with building the reusable framework that others will reuse.  It
is probably a good idea to have them start early, because it usually
takes several iterations to get a good framework.  Unless you have
experienced people who have built this kind of application before,
it might be a good idea to NOT depend on having a framework, since
it is very hard to predict how long it will take.

One way to divide up a project that I know about is to have framework
designers, application class designers, and application configurers (a 
lousy name, I know).  The application configurer is the person who talks
to customers and tries to build what they want.  This person wants
to do as little programming as possible.  If the framework does
not satisfy the needs of the customer, this person will either complain
to the framework designers or (more likely) get an application class
designer to build what is necessary.  The application class designer
is more of a traditional programmer, using the framework and producing
classes that fit into the framework.  Usually the application
configurer is in charge of testing.

Large projects will have lots of frameworks, some of which will be
reused by different projects.  Thus, a project will need to have
someone to coordinate the various frameworks.  Usually a project
will have a chief architect, who will do the coordination.

One of the real problems of writing reusable software is figuring
out who is going to pay for it.  It is quite likely that there are
several groups using the software, and issues of reembursement and
control can be hard to solve.


Brought to you by Super Global Mega Corp .com