TECHNIQUES OF THE PAST

The early days of programming were complex and involved massive amounts
of labor that yielded little results when compared with those of today. Many
readers of this book are probably unfamiliar with what it was like. Although you
can imagine punched cards, batch processing, and time delays for getting results
from testing, it is difficult to imagine the pitiful editing, debugging, and testing
tools. Hours were spent reading a hexadecimal memory dump to see what hap-
pened with a specific program that blew up. Although COBOL and FORTRAN
helped, the problems persisted. This environment clouded the approach that was
taken in implementing systems.
First, there had to be a life cycle. That is, you had to nail down requirements.
That was because if you allowed later changes in requirements, the design and
programming would unravel. Months of work could be lost. So business units
had to sign off in blood that requirements were final —even if they did not un-
derstand them. Similarly, for purposes of control, the design had to be com-
pleted, and signed off by the users prior to programming. Aspects of the design
sometimes could not be implemented due to the limitations on the technology.
A second impact was on documentation. Because the source and object code
were difficult to read and understand, it was necessary to attempt to use various
documentation aids. Flowcharts, decision tables, and so on were developed and
used. However, due to the limited resources, little of this documentation was
ever maintained. Moreover, the designers were sometimes not programmers;
thus, when the programmers got the design, they would throw it out and start
over again (good design, but impractical).
Third, structured methods were in turn developed to try to improve efficiency,
exibility, and communications among the team of developers. Few of these
methods actually worked. Surveys show that of literally hundreds of methods
developed, few or none are in business use today. Why, especially because some
actually were beneficial? They were too hard to enforce and validate. In one case
of success for a programming method, the manager took all the code home over
the weekend and reviewed it. With this level of oversight, it is no wonder that the
staff followed the method. What is the lesson learned here? The lesson is that a
tool must be capable of being monitored and measured in use. Otherwise, how
can you determine its benefits or impact?
A fourth problem was business unit involvement. Previously, there was little
for business people to do on the project. They could not understand the code or
do much testing due to its complexity. When implemented, the system or technology would work side by side with the business process. Because the
system was so unwieldly, there was no real hope of merging or melding these
together. The classic movie example of this was “Desk Set” with Spencer Tracy
and Kathryn Hepburn, where departments were to be computerized and made
efficient through batch processing. It was a classic failure.
This limited discussion provides the background of why people behave in the
old ways and why belief remains strong in traditional methods. You know that
things have changed in terms of tools, methods, the power of the technology, and
attitudes of business. Yet, there are still old patterns and habits that are difficult
to break. After all, people still teach younger students the old methods.
However, not all of this can be thrown out. There is a need for an organized
approach. To an extent, it has to be somewhat sequential. But you will probably
agree that an overall approach should re ect modern conditions.