The world is full of bad logic. We encounter it (and, yes, commit it) every day.
Here’s a trivial example, which we have all encountered in some form at some time:
“The 216 people in this study all ate carrots for at least 2 years, and 58% of them developed disease X. Clearly there is a cause-effect relationship at work involving the orange coloring agent in carrots and disease X.”
When you phrase it that crudely, it’s obviously nonsensical. But dress it up with better camouflage and a more subtle or complex scenario, and it’s a trap that’s fallen into continually.
Here’s a classic example. It’s called The Railroad Paradox.
Gerald M. Weinberg, Rethinking Systems Analysis and Design (Boston: Little, Brown and Company, 1982), Pp. 56-59
The Railroad Paradox
About thirty miles from Gotham City lay the commuter community of Suburbantown. Each morning, thousands of Suburbanites took the Central Railroad to work in Gotham City. Each evening, Central Railroad returned them to their waiting spouses, children, and dogs.
Suburbantown was a wealthy suburb, and many of the spouses liked to leave the children and dogs and spend an evening in Gotham City with their mates. They preferred to precede their evening of dinner and theater with browsing among Gotham City’s lush markets. But there was a problem. To allow time for proper shopping, a Suburbanite would have to depart for Gotham City at 2:30 or 3:00 in the afternoon. At that hour, no Central Railroad train stopped in Suburbantown.
Some Suburbanites noted that a Central train did pass through their station at 2:30, but did not stop. They decided to petition the railroad, asking that the train be scheduled to stop at Suburbantown. They readily found supporters in their door-to-door canvass. When the petition was mailed, it contained 253 signatures. About three weeks later, the petition committee received the following letter from the Central Railroad.
Dear Committee,
Thank you for your continuing interest in Central Railroad operations. We take seriously our commitment to providing responsive service to all the people living along our routes, and greatly appreciate feedback on all aspects of our business.
In response to your petition, our customer service representative visited the Suburbantown station on three separate days, each time at 2:30 in the afternoon. Although he observed with great care, on none of the three occasions were there any passengers waiting for a southbound train.
We can only conclude that there is no real demand for a southbound stop at 2:30, and must therefore regretfully decline your petition.
Yours sincerely,
Customer Service Agent
Central Railroad
This is a true story. If you find it hard to believe, try these stories from a bit closer to home:
-
A systems analyst in a consumer products company heard that some marketing representatives housed in an auxiliary building might need terminals to access the new marketing information data base. He circulated a questionnaire, which included the question:
“How much use do you presently make of the marketing data base?”
People in the auxiliary building, having no terminals unless they cared to walk six blocks, showed zero usage. The analyst concluded that no terminals were required in the auxiliary building.
-
A systems analyst in a large university was preparing the allocations of “computing dollars” to the departments for the coming year. The anthropology department was asking for $10,000 of computer time, but during the past year they had used no computing time at all, even though their budget was $400. The analyst raised their budget to $500, though he really wanted to cut it, as the anthropologists had not used the computer at all in the past. Of course, the project they had in mind would cost a minimum of $8,000 just to get started, but they had nothing to spend on computing unless it was in the budget.
-
A systems analyst in a brokerage firm received a request to change the algorithm by which stock movements were forecast. She surveyed the individual brokers, asking:
“How frequently do you use the stock movement forecast?”
When they all replied that they never used the forecast, she turned down the request. Of course, the reason the forecast wasn’t used at all was that there was an error in the current algorithm, rendering the output worse than useless.
-
Engineers at a computer manufacturing company were asked to improve the new version of the company’s CPU by adding an efficient mechanism for subroutine calls. After a two-month delay, the engineers responded that they had studied a sample of existing programs and found that hardly any of them used subroutines in situations where efficiency was required. Therefore, they said, the request was frivolous, and would be denied.
Perhaps you now see what is meant by “The Railroad Paradox.” Perhaps you would like to add some examples out of your own experience with systems analysis. They aren’t difficult to find—when other people are the perpetrators. The real trick is to catch yourself acting in the role of “customer service agent” —an agent whose relationship to customer service is the same as that of the county rat agent to the county’s rats.
Baldly stated, the Railroad Paradox is this:
- Service is not satisfactory
- Because of 1, customers don’t use, or underuse, the present service.
- Also because of 1, customers request better service.
- Because of 2, the systems analyst denies the request, 3.
In short, because the service is bad, the analyst denies the request for better service.
If we allow ourselves to be bound hand and foot by the Railroad Paradox, our systems aren’t ever going to get much better. The problem is sometimes solved by the customers getting sufficiently violent with the systems analyst. But isn’t there some way we can save our heads and our jobs?
Here are some ideas for an analyst who wouldn’t like to be a rat agent:
-
Be aware of the Railroad Paradox. Be sure you understand its unbreakable logic.
-
Never use customer questionnaires without a certain amount of open-ended discussion with a few of the customers to interpret the meaning behind their answers.
-
Use present levels only as a guide, never as a standard, for future performance.
-
If possible, supply some kind of trial of the new service before deciding to discard it on the basis of poor present use of the old service.
A trial is the most effective test, but does have problems itself. If a service is new, and the old service was bad or nonexistent, a long start-up period may be required. Also, in some systems, users may be wary of getting “hooked” by a trial that they can’t rely on being continued. For instance, if they had to change software to use a new computer feature, they wouldn’t make the investment unless they were assured that the feature was going to remain in the standard compiler.
Quite often though, the trial can be made a low cost and risk to both parties. Central Railroad could have tried a stop at Suburbantown for a month or two with little difficulty. The consumer products company could have provided dial-up terminal service to the auxiliary building for a limited time. The anthropology department could have been given a special supplemental budget for one year, on condition that they would have to use it or lose it. The brokerage could have provided a manually computed stock movements forecast for a few weeks with little commitment.
Of the cases cited above, only the argument against efficient subroutine linkage might be difficult to give a genuine trial. The cost might be great, and programmer behavior might be hard to change. Perhaps that’s why this particular piece of railroading has been going on for more than twenty years!