A hopefully diverting piece from Chris Robbins - K4U
This is something I wrote years ago when I was still usefully and
gainfully employed in the world of mainstream computing, when Bill
Gates had only a few millions to his name and most windows were still
of the glass variety.
It was written with other programmers in mind (but hopefully will
nevertheless prove of interest to other members of 8 Bits) and
concerns my even earlier experiences as a mainframe programmer, back
in the days of punched cards, paper tape, and large air conditioned
computer rooms where the mighty mainframe e.g. IBM 360s and 370s were
housed in almost clinically clean comfort. These now antique monsters
consumed vast amounts of electrical power, but had a performance that
Clive Sinclair's or Alan Sugar's electronic offerings would have
laughed at.
SOFTWARE ARCHAEOLOGY
Writing new software is a creative process, under the control (to a
greater or lesser extent) of the programmer writing that software.
They are in a position to exercise their own judgement, and control
the way in which the software is constructed. It's this very
creativity that makes writing new software so interesting, and the
reason why, given the chance, most programmers, would opt for creating
new programs rather than maintaining old ones.
Certainly I've found that people new to programming, find it easier
and a lot more enjoyable to write something that they've devised,
rather than modify an existing piece of software. But for all of us,
there comes a time when we have to maintain somebody else's code. The
first occasion is seldom a pleasant experience. But given sufficient
time and exposure to software maintenance, it's almost possible to get
to like it.
Well written, documented, and controlled software, doesn't usually
present any problems. It may be a bore to modify it, and to go through
the subsequent validation and re-issue process, but it's usually
fairly painless and straightforward. No, the problems arise with old
(and sometimes not so old) code that's never been properly controlled,
and has little if any documentation associated with it. There is
unfortunately a lot of it about, as most programmers will agree. The
carefully controlled and well documented variety is not as prevalent
as it might be.
Faced with the prospect of modifying such poorly supported software,
one might be excused feelings of irritation, annoyance, or even on
occasion, complete apathy. But there are other ways of looking at it.
You could try treating it as an intellectual puzzle, a cross between a
jigsaw and a crossword, perhaps. Or, more appropriately for the senior
programs, a sort of software equivalent to archaeology. After all,
it's much the same sort of job, digging into the code, seizing on any
clues you can find, and trying to fathom out how it works. It's a bit
like digging up the left over odds and ends of an ancient
civilisation, and trying to work out what it was like. A pottery shard
here, a piece of broken bone there, a post hole or three; all these
can provide clues to the daily life of the people in those times long
past. Valuable clues, which in the absence of any written history, are
the only guide.
A skilled software archaeologist, will have acquired a nose for clues,
almost a sixth sense, that will enable them to unravel the mystery of
an obscure piece of code. By examining fragmentary comments, variable
names, programming techniques, and exposing the underlying foundations
of the code layer by layer, an experienced archaeologist can, given a
bit of luck, come up with some useful information.
I can still remember my feelings, when many years ago, I was presented
with the task of modifying an ancient Fortran program. They were a
combination of panic and despair. The program was one of a suite used
to generate control tapes for a wire-wrap machine. The machine was
from America, and we'd bought the source code of the associated
software many years previously, to enable us to customise it to our
own needs. If there had been any documentation to start with, there
was certainly none left when I came to look for it. Everyone who knew
anything about it had long since left the company, and needless to say
there was no support in this country for the system. I also had the
minor problem of knowing nothing about Fortran.
Although the engineers who designed the circuit boards to be wired up
by the machine, knew how to specify what pins were to be connected to
what, they had no idea how it was done, or how the control tapes were
compiled. Every so often they would submit a batch job to produce the
required tape, using as a basis a previous job they'd submitted.
Having worked so well for so long, they now wanted to make a 'minor
change' to the way in which pins were wired up. This necessitated a
'small change' to the format of the tapes needed to drive the machine,
and hence the tape preparation software. And I was the person
'lumbered' with doing it.
My mood changed to one of irritation when I discovered the general
level of ignorance surrounding the system. That feeling was as useless
as panic. I resolved to find out how it worked, and hid myself away
for several days while I pored over the source listings. The code was
obscure to say the least, but it was possible to trace the broad
outlines of its history from the various programming styles. Much like
tracing the rise and fall of an ancient city, from the various
building materials and techniques employed.
Having worked out which was the original code and which the subsequent
customising, really didn't help too much. Not at that stage anyway.
What I really needed, was a sort of Rosetta Stone to enable me to
relate the engineers wire wrap instructions to the coded commands on
the machine control tapes. After a bit more careful excavation I found
what I was looking for. A set of translation tables. But they were all
empty, and there didn't appear to be any code to initialise them.
More patient work scraping away with the programmers trowel, revealed
the use of an obscure subroutine written in assembler, and used to
load the translation tables from an even more obscurely named file. I
was obviously getting somewhere! From that point on it was all down
hill. Within a few days I'd worked out where and what needed changing,
and had made the appropriate modifications. Needless to say I didn't
get any thanks for it, merely criticism from the engineers for taking
so long. After all it was only a very small change to a working
program that they had used for ages, wasn't it? And Fred, who'd
previously looked after it (he'd left two years previously) could have
done it by the very next day!
Obviously the size of the code to be excavated, will determine how
easy or otherwise the task will be, how many exploratory trenches
you'll have to dig, and how long it will take. The wire wrap program
was fairly small by comparison with one I had to tackle a year or so
later. I hadn't been at the installation very long, when I was given
an extremely ancient invoicing system to look after. It had been
written originally (so I was told), for one of the first generation
business computers, a LEO or some such. They may have been kidding me
(I never did find out), but it was certainly old, and very very large.
It was more patches than original code, and if some of the amendment
dates were to be believed, COBOL and it grew up together.
By now I'd become somewhat inured to the pain involved in digging
through compacted layers of antique software, and I'd also acquired a
certain amount of skill in locating important finds. Preparation was
essential, so I set about a systematic search through the pile of
listings I'd obtained.
Fortunately for me (and unlike a number of other large programs I'd
had to maintain) it was highly modularised and fairly well structured.
I managed within a week to locate some of the more important areas.
These would be worth more detailed investigation later. I also managed
to produce a useful ground plan. Soon afterwards, I was asked to make
a minor change (why are all changes considered to be minor?) to the
system. I was thankful that I'd spent so much time studying it, and
particularly thankful for the ground plan. For, far from being minor,
the change required nearly every module in the system to be modified
in some way!
They must have been expecting me to have trouble, despite calling the
change minor. For, a few days later when I reported that I'd made the
changes, I was greeted with exclamations of disbelief. Previous
programmers, I was told, had usually taken two or three weeks and
numerous attempts, to do similar modifications. When I explained what
I'd done, and mentioned in passing the similarity with archaeology, I
got some funny looks. Apparently no one had previously thought of
being systematic about maintenance, or of doing any preparatory work.
And programming was programming wasn't it? What had it to do with
archaeology? Computers were new and shiny, and archaeology was about
old and dusty things. Despite the initial scepticism, it soon became
apparent that the changes had been duly incorporated, and that they
worked.
In solving my own particular maintenance problem, I'd merely applied
what I'd thought was a common sense approach. It would nice to be able
to say that my approach was seen as amazingly efficacious ( a bit like
Lily the Pink's Medicinal Compound), was applied universally, and
solved everybody else's problems as well. But alas it was not to be.
Maintenance in general was still carried out on a hit and miss basis.
Strangely enough though, one or two of the other members of the
maintenance team, started to take a keen, if surreptitious interest in
archaeology. When caught reading the odd book on Early Dynastic Egypt,
or the collected works of Sir Mortimer Wheeler for instance, they
became embarrassed, and would attempt to casually slide it under a
listing, and out of sight. Curious wasn't it?
THE END