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 five examples relative to your own experience, you will notice two categories:
KEPT: first-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 infinite 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.
Wednesday, November 30, 2011
Subscribe to:
Post Comments (Atom)
3 comments:
I find that I end up being a horrible packrat with code. If I can keep it, I do.. because every time I don't I end up needing it sometime later and having to cobble the solution from first principles again.
This of course means I have a morass of old emails, data, and other cruft on my backup systems I will probably never look at again. But every now and then I find myself having to figure out how some old relic computer was fixed by someone else and relaying that knowledge to someone new.. at which point a large 'find . -type f -print0 | xargs grep -l "SPEW"' occurs. I am glad data is so much easier to store, because I hate keeping papers around that long.
On the flip side I realize that certain programs really outlive their usefulness. At a former workplace, I had the lovely task of getting a specialized editor that had originally been used on some CDC monstrosity of the 1960's. Written in Fortran IV it had been ported/patched/punted along from PDP->Cray->SGI->Digital OSF/1 and finally to Linux. It was kept because its interface was well known by the old guard, and taught to various generations since then. Re-implementations usually failed due to the idea that it was always faster and cheaper to port it one more time than rewrite it. It was a mess of code which made Emacs look simple.. sadly I got reassigned after I got it to compile and some poor grad student had to spend their next year fixing it.
Hi Smooge,
You really bring back memories. Just one example you'll recognize. We had a program on the IBM 650 (whose main memory was a drum!). The engineers liked it, so it was run on a 650 emulator on the IBM 704. Then the 704's 650 emulator was ported to a 704 emulator on a 7090, which was then emulated on a STRETCH computer.
I don't know if it was carried any further, but though the STRETCH was then the world's fastest computer, the program ran slower than it did on the original 650.
I suspect it didn't go further because any slower and it wouldn't have been usable. There's some doubt whether it was usable even on the original 650.
Hi Jerry,
Why we keep programs (that we indeed should dispose of)? Reasons that I hear:
- We are afraid to throw something away, we might need later
- We don't like decisions, and it's easier ton non-decide (and to keep it) then to decide to throw it away
- We've spend so much time, we don't want to lose our investment
- We can always improve it later, lets keep it for now
Most people hate taking decisions, and have worries that they take the wrong decisions. This is in my opinion one of the root cause we have so much horible software, that should have been disposed.
I've had occasions where I lost a program, or a piece of documentation, a blog text or a presentation by accident. I didn't feel good when it happened, and I tried to get it back. Finally I gave up and rewrote it. The second version has always been better, and it took only a small amount of time to create it. Why? Because the thinking to create the first version was most of the work. The creativity took most of the time, typing it didn't take much. And when I re-create it, I often get new insights which make it better.
So, I fully agree. When you want to keep something, throw it away. If it really feels as a loss, re-create it and you will have a better version. If it doesn't feel that you lost something, then there is no problem anyway, so you did the right thing to throw it away.
Post a Comment