🚀 go-pugleaf

rsd@sei.cmu.edu (Richard S D'Ippolito) writes:
> ... rcd@ico.ISC.COM (Dick Dunn) writes:
[about the hard-to-pin-down adaptability needs]
> >..."must be able to
> >survive the next five years of changes, to meet new needs,...

> There are ways to do it.  One can generally anticipate the areas of change,
> especially in large systems where there is a long history of changes.

Yes, you can anticipate some of the needs.  But there's a whole continuum
of possible changes.  Some future needs are so explicit that you can
actually put provisions in your requirements that the code be "ready" for
the changes--in effect, what you do is specify and design for a feature;
you just don't implement it.

Next along the spectrum is the type of change Richard is talking about--
You may not be able to pin down the exact change you'll need, but you know
the general area and direction.

The type of change I'm interested in is all the way down at the other end
of the spectrum...the changes which will eventually come about because
someone comes up with a need and says, "Wait a minute!  What about the
xyzzy program?  Doesn't it do a lot of this stuff?  Could we adapt it to do
what we need?"  It may be an adaptation of the program to add a capability,
or you might clone the program and transmogrify the clone.

I don't have many clues of how to characterize or measure the adaptability
of code to such unanticipated needs.  I'm not even sure it makes sense to
try to measure it.  But I do know that it's common to look at recycling
code this way...and I know that "quality code" will allow it to happen.

It's hard to make analogies with other areas of engineering about this sort
of change, because software is so much more mutable.
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...No DOS.  UNIX.