Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!mailrus!utah-gr!utah-cs!defun.utah.edu!shebs
From: shebs%defun.utah.edu@utah-cs.UUCP (Stanley T. Shebs)
Newsgroups: comp.software-eng
Subject: Re: How will your code look to the hot-shots of 1993?
Keywords: Software Maintenance
Message-ID: <5623@utah-cs.UUCP>
Date: 22 Jul 88 17:03:13 GMT
References: <12398@agate.BERKELEY.EDU>
Sender: news@utah-cs.UUCP
Reply-To: shebs%defun.utah.edu.UUCP@utah-cs.UUCP (Stanley T. Shebs)
Organization: PASS Research Group
Lines: 34

In article <12398@agate.BERKELEY.EDU> bks@ALFA.berkeley.edu (Brad Sherman) writes:

>Everyone seems to have a plan for producing good software, but could we
>have some discussion of how to go about fixing and modifying existing code?
>[...]  How should a programmer go about internalizing enough of the
>workings of the system to have a shot at succesful completion?

Seems like I've spent half my programming career doing this, with everything
from old and crufty Fortran to old and crufty Lisp.

My preferred practice is to start by making one attempt to read through the
code to understand it.  If this succeeds, then the code is good.  If not,
then I start adding comments for the bits I do understand, with lots of
questions.  At the same time, I start doing local transformations on the
code - changing into a more modern dialect/usage, flushing fragments that
aren't really used, moving things in and out of loops, being careful all
the while to make sure that correctness is preserved.  At this point, only
local understanding is needed.  As time goes on, larger patterns start to
appear, I understand more of the total program, can revise the comments
to reflect that improved understanding, and can make more sweeping changes.
In several cases, I've ended up with a nearly total rewrite that is easier 
to understand, better commented, faster, and more general than the original.
This process has also uncovered long-hidden bugs on more than one occasion!

Caveats:  This is harder to do if the code must be left alone - the comments
and transformations have to be somewhere else.  It also requires care and
backups and frequent testing to make sure that things haven't gotten broken
by the apparently innocuous change.  The time and effort is substantial,
so it's more practical for individual routines than major systems.

One way to look at this is that it's the application of hacking energy to
reverse program entropy...

							stan shebs
							shebs@cs.utah.edu