Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!agate!ALFA.berkeley.edu!bks
From: bks@ALFA.berkeley.edu (Brad Sherman)
Newsgroups: comp.software-eng
Subject: How will your code look to the hot-shots of 1993?
Keywords: Software Maintenance
Message-ID: <12398@agate.BERKELEY.EDU>
Date: 22 Jul 88 05:08:36 GMT
Sender: usenet@agate.BERKELEY.EDU
Reply-To: bks@ALFA.berkeley.edu (Brad Sherman)
Organization: University of California, Berkeley
Lines: 22

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?

For example, given a working software system that began its life-cycle, say,
5 years ago. That has been through patches, bug-fixes and customer
requested feature additions.  That was written using the state-of-the-craft
design methods of an above average programmer of 1983.  In other words,
it works most of the time and no one is going to give you the luxury of
a complete rewrite using the design methods of 1988 and your own peculiar
idioms.  Unfortunately, the original programmer is now designing graphics
boards for the Estonian division of MegaCorp.  System consists of 8 programs
written in C ( remember, 1983 style ) about 20000 lines total. Documentation
is sparse and out of date.

Your job is to make it work on the new improved and almost compatible hardware
and revised O.S., and oh yes, please add these 4 features while you're at it.

I think that this task is more typical than most that have been discussed in
this group.  How should a programmer go about internalizing enough of the
workings of the system to have a shot at succesful completion?

		--Brad Sherman