In many IT installations today, the number one problem is program maintenance.
Although the total problem is far from simple, there are a number of relatively simple ideas that can be applied immediately to furnish "prompt relief." One such idea is the disposable program.
The idea of disposable programs is not new. Every programmer has written code that was to be used once and then thrown away—codes such as:
1. First-cut subroutines, as for simple, quick formatting of output.
2. One-time reports.
3. Test drivers.
4. Research programs to probe some peculiar feature of the programming language, operating system, database, or other "black box."
5. Engineering assist programs, to help diagnose a particular hardware malfunction.
If you consider these ﬁve examples relative to your own experience, you will notice two categories:
KEPT: ﬁrst-cut routines, and one-time reports, and
DISPOSED: test drivers, research programs, and hardware testers. That is, though all are thought of as single use programs, the KEPT routines tend to be held, somewhere, "just in case." Only the DISPOSED programs are actually discarded, whether they should be or not.
Can you recall an instance when you wished you had actually retained a discarded program?
And can you recall cases of KEPT programs you devoutly wish you had destroyed when you had the chance? These are the programs you see and curse almost every day, as their user phones, pleading for "just one little change."
Perhaps we would immediately begin improving the maintenance situation by applying two simple rules about "one- time" programs:
1. If you are about to throw it away, keep it.
2. If you are about to keep it, throw it away.
Unfortunately, applying these two rules together creates an inﬁnite recursion. All programmers would be instantly paralyzed. There must be a better way. (Or do you believe that instant paralysis of all programmers would be of great benefit to the human species?)
Consider the examples once again; you'll notice that the underlying principle seems to be:
If the programmer is responsible for the decision, the program is discarded; but if the user is responsible the program is kept.
But why not just keep all programs, for all time? There are many reasons why a program brought out of hibernation could incur costs:
1. The hardware environment has changed.
2. The system software environment has changed.
3. The size or format of the data has changed.
4. The human environment has changed.
5. Some part of the program or its supporting material has been lost or damaged.
So it does cost to rerun an "unchanged" program, and the longer the period of hibernation, the greater the cost. But you already knew this—we all know this. Then why, oh why, do we keep tumbling into the same trap? And how do we get out, or stay out, of the trap.
Well, we'll watch for readers' ideas on these questions, and next blog entry, I'll give a few ideas of my own.
Where Do You Have Redundancy?
4 days ago