Wednesday, February 27, 2013

Special Questions




Note: The following tale is adapted from my book, Rethinking Systems Analysis and Design. What's the moral of this tale? After you make your own suggestions, take a look at the original tale and see what the book has to say.




Harlan Mills predicted that some day programmers will make so few errors that they'll remember every one they ever made in their entire career. I've had a long career and I've made rather more than the one error per year that Harlan predicted. One a day might be more like it. But some errors were so gross or so costly that they stand out among the thousands.

Over forty years ago, I was analyst/programmer for a service bureau studying a job that involved processing a million cards through the IBM 650 computer. Because of limitations on the 650's ability to read cards, the only punches allowed in the cards were alphabetics and numerics. Special characters could not be read at all.

When questioning the client in our very first meeting,I asked, "Are there any spetial characters in the cards?"

"No," he replied, "none whatsoever."

"Good," I said, "but I have to be sure. Are you certain that there are no special characters at all?"

"I'm quite certain. I know the data very well, and there are no special characters."

On that assurance, we went ahead with designing and programming the application, only to discover on our first production run that the system was hanging up on cards like this:
THREADED BOLT—1/2" #7
About sixty-five percent of the cards contained special characters, but when I confronted the client with this figure, he appeared genuinely puzzled, "But there are no special characters," he pleaded.

"Oh, no," I said triumphantly, "then what about this dash, slash, quote, and number .sign?"

3 comments:

Franklin Chen said...

Depending on how the rest of the story turns out, the moral of the story could be either (1) he had a misunderstanding of what a "special" character is, or (2) never assume input is what you expect, but always check it.

Franklin Chen said...

Depending on how the rest of the story turns out, the moral of the story could be either (1) he had a misunderstanding of what a "special" character is, or (2) never assume input is what you expect, but always check it.

Joe Harter said...

I'd like to guess at the moral.

In a nutshell, I'd guess that the moral is that language is a powerful but incomplete method of communication. Until we master ESP, we will make mistakes when trying to communicate with each other, and in this case it appears that two different people had different ideas of what "special" meant in this context.

What is the right solution though? We can't ask a person to define every word they say or type. Will they then have to define the words they used to define those words?

Instead, we need to create some kind of framework when doing work for other people to help mitigate this issue. I will check the book to find out how you kept these mistakes from happening in the future. I think a reasonable response is to get sample data from customers, and perhaps explicitly tell the customer what data will be valid or invalid in your own program.