Gems from Old Software Books #1

Of all the requirements that we might place on a program, first and foremost is that it be correct. In other words, it should give the correct outputs for each possible input. This is what we mean when we say that a program “works”…

 

An example may serve to drive home this point to those whose minds are tangled in questions of efficiency and other secondary matters. A programmer was once called to Detroit to aid in the debugging of a new program—one that was to determine the parts requirements to build a certain set of automobiles. The input of the program was a deck of cards, each card representing a purchase order for an automobile, with different punches representing the different options selected by the customer. The program embodied the specifications relating the various options to the parts that would be needed. …

 

Unfortunately, when this programmer arrived on the scene, the basic approach to the problem had long been settled—and settled badly. Each option—as it affected each choice—was reflected as an individually programmed test and branch in the program. In a way, the program was an enormous tree, with more than 5,000 branches, representing the decisions leading to part selection. Cast in this form—and with 16 programmers working at the same time—it was impossible to debug, as each and every case had to be tested separately. To test the program, a particular card would be put in and the output would be observed. When our programmer arrived, things were so bad that typical cards were calling for the production of cars with eight tires, no engine, and three sets of upholstery. In short, a disaster.

 

As usual with programming disasters, nobody recognized it as such. Instead, the whole crew had gone on double shift to get out the bugs, and new programmers, including our hero, were brought in from all over the country. Naturally, this led to worse confusion than ever, and our programmer, after a few days, determined it was hopeless business … He was roundly condemned for his uncooperative attitude but was allowed to leave.

 

While on the plane, he had the first opportunity in a week to reflect calmly. He immediately saw the error in the approach and perceived that a much better approach would be to divide the work into two phases. [Solution details elided]

 

By the time he got off the plane, he had coded the two programs [writing the code out by hand on paper, no doubt!]. It was a day’s work to check them out, and another two days’ work with the local assembly plant engineers to create the specifications in input form. … then he was asked to make a presentation to the rest of the programmers. Naturally, they were a rather cool audience…but they sat quietly enough through his explanation of the method. Even at the end, there was a lack of questioning—until the original creator of the old system raised his hand.

 

“And how long does your program take?” he asked—emphasizing the possessive.

 

“That varies with the input,” was the reply, “but on the average, about ten seconds per card.”

 

“Aha,” was the triumphant reply, “But my program takes only one second per card.”

 

The members of the audience—who had, after all, all contributed to the one second version—seemed relieved. But our hero, who was rather young and naïve, was not put down by this remark. Instead, he calmly observed, “But your program doesn’t work. If the program doesn’t have to work, I can write one that takes one millisecond per card—and that’s faster than your card reader.”

 

This observation—though it undoubtedly failed to win our hero any friends—contains the fundamental truth upon which all programming evaluation must be based. If a program doesn’t work, measures of efficiency, of adaptability, or of cost of production have no meaning.