A colleague recently posted this story on a software quality mailing list. You may have seen something like it before. You may have lived through something like it before.
In March 1992, a man living in Newton near Boston, Massachusetts received a bill for his as yet unused credit card stating that he owed $0.00. He ignored it and threw it away. In April he received another and threw that one away too. The following month the credit card company sent him a very nasty note stating they were going to cancel his card if he didn't send them $0.00 by return post. He called them and talked to them about the problem. They said it was a computer error and told him they'd take care of it.
The following month our hero decided that it was about time that he tried out the troublesome credit card figuring that if there were purchases on his account he could end this ridiculous predicament. However, in the first store that he produced his credit card in payment for his purchases he found that his card had been cancelled.
He called the credit card company who apologized for the computer error once again and said that they would take care of it. The next day he got a bill for $0.00 stating that payment was now overdue. Having spoken to the credit card company the previous day, he assumed the latest bill was yet another mistake he ignored it, trusting that the company would be as good as their word and sort the problem out.
The next month he got a bill for $0.00 stating that he had 10 days to pay his account or the company would have to take steps to recover the debt. Finally giving in, he thought he would play the company at their own game and mailed them a check for $0.00. The computer duly processed his account and returned a statement. It reported that he now owed the credit card company nothing at all.
A week later, the man's bank called him asking him what he was doing writing a check for $0.00. After a lengthy explanation the bank replied that the $0.00 check had caused their check processing software to fail. The bank could not now process ANY checks from ANY of their customers that day because the check for $0.00 was causing the computer to crash.
The following month the man received a letter from the credit card company claiming that his check had bounced and that he now owed them $0.00. Furthermore, unless he sent a check by return of post they would be taking steps to recover the debt
The man, who had been considering buying his wife a computer for their anniversary, bought her a typewriter instead.
It's a cute story. Yet this sort of story troubles me, since it subtly absolves people of responsibility. It places the blame on computers and not on requirements people, programmers, testers, test managers, and business managers, where it belongs. For example,
They said it was a computer error and told him they'd take care of it…
In that sentence alone, there are two lies being told. First, they told him they’d take care of it (and they didn’t), and second, they told him it was a computer error (and it wasn’t). You may think that I’m splitting semantic hairs here, but you never hear that a patient died in surgery because of a scalpel error; a speed skater doesn’t lose the Olympic gold medal because of a skate error; nor do you hear about a dam bursting because of a cement error. I think that the language that we use in retelling such stories needs to be modified to emphasize that this is not a story of a technology problem, but of a whole bunch of people problems.
For some reason, the computer industry has been expertly deflected responsibility from itself for the problems that it causes, or that it doesn’t bother to fix. Programmers who play this game, but sales and support people, marketers, and especially the managers are in on it--and sadly, customers have been duped into playing too.
Let me give you a thought experiment. You leave your car with the mechanic. You can't pick it up until 6:30pm, so the mechanic arranges to leave the keys with The Guy in the Booth. After you pay the bill and retrieve your keys, you put the key in the ignition, and turn it. The car goes "yawp!" briefly, and then dies. What do you say? One thing you could say is, "Well, shucks, I don't understand why this isn't working. I guess I'm just too stupid to understand these car thingies." But I suspect you don't say that; instead, you are quite rightfully upset with the mechanic. You know that someone—some person, not some machine--has failed you and left you stranded. Yet how has the computer industry has managed to convince you that problems with the computer are your fault? That you're stupid, because you don't understand their software and technology that doesn't work and that is poorly documented
Why is this sort of thing an issue to me? Well, it’s partly self-interest—I speak at seminars in which I try to get people to understand that many, many software errors could be prevented if only we thought a little more carefully. But there’s a political angle here too. Sensible people believe that, in and of itself, technology can’t solve anything. Over the last 25 years or so, certain politicians have been trying to tell us that the correct solutions for political and social problems are always business-style solutions. I disagree with that, and I think we need to be reminded as often as possible that businesses regularly make stupid mistakes such as the ones that appear in the story. And before the Libertarians start up on me, yes, government organizations can make stupid mistakes too—but I would argue that running governments like a business is often the problem.
Thus I believe it’s important to reframe this article; adapt the language a little so that it’s absolutely clear that it’s NOT a computer problem; it’s a business problem, a management problem, and ultimately, a people problem.
Here’s what I’ve done: “The bank” might send him a threatening letter of some kind, but I’ve made sure that the customer never talks to “the bank”; he only talks to people. Computers—machines that do nothing without human instruction—are not mentioned, except when someone who doesn’t know what the problem is uses the computer as the object of blame. And I’ve fictionalized a little, making guesses at the real problems. So, here’s that article again:
In March 1992, a man living in Newton near Boston, Massachusetts received a bill for his as-yet unused credit card stating that he owed $0.00. He ignored it and threw it away. In April he received another and threw that one away too. From long experience, he realized that talking to a customer-service department was a time-wasting proposition.
The following month, the software that had passed the departmental managers’ cursory review and testing processes set a flag, and automatically printed a nasty form letter stating the bank was going to cancel his card if he didn't send $0.00. Because hiring sufficient number of people would cut into the bank's profits, the managers had decided that no human ever had to read threatening letters. In fact, other than the first one, no human had to write, review, or even sign them; the managers had abrogated all responsibility and had automated the process completely, right down to the machine that “automates” (or, in plain language, forges) a human signature.
Our hero called an unempowered customer service representative and talked to her about the problem. She followed her training and lied to him, saying it was a computer error and that the bank would take care of it. (Computers don’t make errors and banks never take care of anything; people do.) She realized that she was making waves, against the unwrittens rule in the Customer Service department, but the customer service representative reported the problem to her supervisor. He shrugged and said that someone in Systems would probably notice it—although he didn’t realize that the department called Systems had been split into three different divisions two years ago. He didn’t report the problem, but that didn’t matter, since there was no way that anyone could be identified as having ignored a customer complaint; the supervisor’s manager didn’t require records of that sort of thing.
The next month our hero decided that it was time to try out the troublesome credit card, figuring that if there were purchases on his account he could end this ridiculous predicament. However, in the first store that he produced his credit card in payment for his purchases he found that his card had been cancelled; the people responsible for the writing the software requirements hadn’t bothered to set a bottom limit on a minimum billing, the people responsible for review hadn’t picked up on the omission in the requirements, the programmers hadn’t really thought about the problem and had simply expressed the requirements in code, and the testers hadn’t run one of the most obvious boundary checks imaginable.
Our hero (who, by this time, was feeling more victim than hero) called a different customer service representative at the credit card company who apologized for a “computer error” once again and said that he would take care of it. The rep's supervisor wondered why nobody from Systems had noticed the problem, and then he shrugged and went on to something else.
The next day our hero got a bill for $0.00 stating that payment was now overdue. Having spoken just the previous day to a person at the bank who had committed to resolving the problem, he assumed the latest bill was yet another mistake. So he ignored it, trusting the customer service rep to sort the problem out. The next month he got a bill for $0.00 stating that he had 10 days to pay his account or the company would have to take steps to recover the debt. Finally giving in, he thought he would play the bank's game and mailed it a check for $0.00.
The data-entry person who processed the check thought it was odd that he should be entering a value of $0.00, but the last time he had asked his manager a work-related question, the manager had snapped at him and said, “Just do it, for God’s sake!” Meanwhile, one programmer, working solo, had put in code to special-case a zero entry; this was used to shut down the system entirely in case an error was discovered during automated testing. (The testing was to be performed by personnel from a large accounting firm, which was coincidentally also responsible for the bank’s audit.) Since the programmer hadn’t put a comment in her code, hadn’t told the documentation people about the system shutdown trick, and had left the bank a few months later, nobody knew about the time bomb ticking in the code. The problem wasn’t discovered, even though the testers responsible for the check-processing module were among the best that accounting firm had to offer. None of the people assigned to test the software had any experience or training in testing; they were university co-op students and business analysts who had been accepted testing jobs, rather than being laid off during the recession.
Meanwhile, the software responsible for the $0.00 bill accepted the $0.00 payment, and a payment notice was automatically generated and mailed. Zero balances were not unusual, so that was okay—and the testers had even run the test automation software on that module. However, no one had ever reviewed the test output or the real output either, and no one had bothered to link the cost of sending out a statement to the value of noting a zero payment on a zero balance, and so no one was troubled by the extra expense. Like any business, bank revenues only come from people who pay money to the business—the customers; for all of the bank’s expenses, including errors and the salaries of the managers who are supposed to prevent this sort of waste and nonsense, the customers pay anyway.
The bank’s software now reported that the customer owed nothing at all. The customer’s record had been automatically printed and sent to a clerk for review just before sending the information to a collection agency. The clerk responsible for that step had only looked at the bottom line of the bill, and noting the zero balance, considered the matter closed. Had she looked a little higher on the page, she might have noticed something weird about a zero payment. She was a natural skeptic, and likely to be a good tester, but even if she had noticed the curious payment, she knew that reporting discrepancies wasn’t her job, and that no one would be interested in pursuing the matter.
A week later, the assistant manager of the man's bank branch called him asking him what he was doing writing a check for $0.00. She hadn’t bothered to review his records, and didn't realize that the check was written to their own credit-card division; she only knew that a senior manager in the check-processing division had called her earlier that day, asking her to contact the customer and get some information from him. (Earlier that day, that same senior manager asked a manager in the data-entry division to discipline a data entry clerk for doing something so stupid as to enter a check for a zero amount.) Our hero was confused by the assistant manager’s tone. After lecturing him that whimsical behavior by customers cost the bank time and money, she admitted that the $0.00 check had caused their check processing software to fail—a little like a drunk driver claiming that the fire hydrant had hit his car. The bank’s software could not process ANY checks from ANY of their customers that day. Because of lapses in requirements, review, programming, documentation, testing, and management (which had chosen the cheapest and least robust operating system available) the entire system had crashed. No one had planned for any contingencies at all, so there was no backup system. The bank had pointed a shotgun towards the floor, pulled the trigger, and blasted off its own foot, but somehow it was the customer’s responsibility.
Nobody at the bank addressed any of the root causes, and even the original problem wasn’t rectified. So the following month the man received another automated form letter from the credit card division claiming that his check had bounced and that he now owed the bank $0.00. Furthermore, unless he sent a check immediately the bank would be taking steps to recover the debt.
The man, who had been considering buying his wife a computer for their anniversary, bought her a typewriter instead. Weird, since computers didn’t really have anything to do with this story. Even more oddly, he wrote a cheque to cover the payment for the typewriter; he didn’t see anything wrong with keeping his money in that same bank.
I would like to thank Tamar Yaron for posting the original version of the article in the swtest-discuss mailing list and inspiring my revision of it.
This essay is copyright ©2003 Michael Bolton. If you liked it, please let me know. If you didn't, please let me know how I might improve upon it.
If you'd like to be notified when I've posted another essay that you might enjoy, please click here to be put on my mailing list. If your reply-to address isn't altered to prevent spam, you don't have to put anything in the body of the message.
Best of all, if you (or your company, or your manager, or your employee) need counselling, consulting, or instruction in this area, I can help with engaging and informative courses on quality assurance and software testing in plain English that save your company lots of time and money; contact me by for details. Thanks!
Back to the Essays page…
Back to the DevelopSense home page…