Disposable Programs

©2005 Gerald M. Weinberg

We hear a lot these days about “reusable programs,” but we seldom hear about programs that shouldn’t be reused. Most programmers know what it’s like to be forced to reuse code that was supposed to be used only once and then discarded, such as:

1. prototypes, as for simple, quick formatting of output
2. one-time reports
3. test drivers and harnesses
4. research programs to probe some peculiar feature of the programming language, operating system, databse, or other “black box”
5. engineering assist programs, to help diagnose a hardware malfunction

These examples generally fall into two categories:

Frequently retained when they should be discarded:
protoypes and one-time reports, and

Frequently disposed of when they should be kept:
test drivers, research programs, and hardware testers.

That is, though all are thought of as single-use programs, the should-be-discarded software tends to be held somewhere, “just in case.” Only the should-be-kept programs are actually discarded.

If the developer is responsible for the decision, the program is likely to be discarded; but if the customer is responsible, the program is likely to be kept.

Developers discard programs because they understand tha reuse is not free. A program not designed and test for reuse, but brought out of hibernation will cost even if no requirements changes are requested by the customer.

1. The hardware environment may have changed.
2. The system software environment may have changed.
3. The size or format of the data may have changed.
4. The human environment may have chnaged, which might, for example, activate a part of the program that has never been invoked before.
5. Some part of the program or its supporting material may have been lost or damaged.

The longer the period of hibernation, the greater the cost – if for no other reason than somebody must check for one of these five conditions. But you already knew this – we all know this. then why, oh why, do we keep tumbling into the same trap?

I believe the answer lies in our unwillingness or inability to feed back the true costs of program development and program maintenance to our customers. Many software development vendors have reduced the problem to manageable proportions by the following steps:

1. When a program is commissioned, the customer must specify the lifespan and the number of executuions.
2. If there is uncertainty about either of these figures, the vendor bids contingent prices, reflecting the differing costs.
3. The vendor offers a contract stating that the program will be destroyed after a certain time and/or number of executions, whichever comes first.
4. The program remains the property of the vendor, unless the customer takes ownership. In such a case, the vendor places a much higher cost on the job – to pay for preparing the program to be maintained by other than the original developers.
5. The vendor notifies the customer when the program is about to be destroyed, and gives the option (at a substantial and realistic price) of rebuilding the program for further use.
6. If the original contract was for a “one-time” program, no notification is required. Instead, the vendor destroys all copies of the program as soon as the customer has accepted the program’s output.

Inexperienced customers readily accept these terms. So do very experienced customers, who know quite well the realities of “one-time” programs that turn out to be “N-time” programs. Only the in-between customers have difficult accepting these conditions, for they believe – incorrectly – that they understand programming.

In-house IT organizaitons – especially where there is no true chargeback for development or maintenance – have more difficulty teaching these lessons. The users pay nothing for specifying a one-time program and then asking that it be run N times. Without cost, they have little motivation to learn. With chargeback, however, in-house IT organizations can do what good, professional vendors do.

If you work in an in-house IT organization without chargeback, however, you can sometimes achieve relief by manipulating your one available parameter – time. You ask the customer to specify a one-time or N-time program and then give different time estimates for each. The one-time estimate is shorter, but carefully spells out the procedure that will be followed in destroying the program after its first use. Initially, users simply will not believe you will enforce this procedure, so get it in writing. After a few lessons – if you don’t submit to screams and threats – they will begin to understand the true costs. Only then will they devote some energy to making their initial decision of one-time versus N-time.