Spaghetti
Software
(Evolution of
Programming Methodology, Part I , Page 2)
By Bill Nicholls
February 28,
2000
Describing
the programming style of those days as 'ad-hoc' is accurate
for most and flattering to some. Whatever worked was good,
what didn't was bad. Specifications? Here's a sheet of paper
torn from the professor's scrapbook. Testing? It compiles
and runs the single hand-checked example -- it must be OK.
The only way to look back at those days calmly is to
understand the scale of the jobs was much smaller, and many
could be handled by one person in a few weeks to a few
months. Student programs were another ball of twine
entirely.
Fortran, with GoTo and the suicidal Computed GoTo, was
the source of innumerable spaghetti threaded programs.
Modifying one of those was an exercise in masochism. They
were tottering structures of glass, balanced in the tip of
the pinhead that wrote them. In those early days, few people
knew better methods and nobody was talking about 'computer
science.' By analogy, an untrained person with a hammer and
saw had a better chance of building a house that stood than
these programmers had of building a solid program. I
remember it well, I was one of them.
To a great extent, we were saved by the limited scale of
the equipment that was available. Big jobs were broken down
into several runs with data written to tape and read back
in. The computers limited the size of the programs, which
forced a form of partitioning, though with little
organization. A big system had 64K words of 36 bits, a drum
for OS and small scratch files, and slow tapes for
everything else. Most projects those days fit easily into
the system, and on the multiprogramming OS, we could run
three or even four small tape jobs at the same time. Wow.
The Programming Activity
The best known early
paper that addressed building programs was "Programming
Considered as a Human Activity" by E. Dijkstra in 1965. Long
before most of us had a clue on how to create good programs,
his five-page paper spelled it out clearly. Actually doing
what he suggested was rather more difficult, but concepts
like elegance are still essential to building excellent
programs. This paper is so clear that it rewards reading
time after time.
In 1967, another paper, "GoTo Considered Harmful" by E.
Dijkstra is probably the best-known attack dealing with
specific problems of programming large jobs. By then, some
systems had a megabyte or more of memory and were big enough
to enable programmers to machine gun themselves in the
knees. For many, it was a difficult transition. Avoid GoTo?
How?
Subroutines became the answer for all such
problems. The early uses of subroutines were restrained and
effective, clearing the way for larger programs to be
written. Soon subroutines proliferated and, like cockroaches
in a dirty kitchen, became the source of another set of
problems. There were no standards for choosing what to
extract for subroutines or how to pass parameters.
<<<Previous
Page >>>Next
Page
