eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
My letter of last week, urging that systems be designed to doubt themselves, generated a surprising amount of reader mail for a week when so many offices were closed and so many people were taking time off. Three themes emerged.
i) Systems cant be designed to be idiot-proof, at least not at any reasonable cost, because society continually develops better idiots.
ii) Systems shouldnt be designed to be idiot-proof, because people do better work when they stay engaged in the process and because overly complex systems just get in the way.
iii) Systems will never be idiot-proof as long as people are willing to spend time and money on writing and debugging business logic but cant be bothered to develop business process models or put instrumentation into the business environment.
The history of the Internet is filled with examples of the first theme. In one notable incident, a message header contained a tab character that didnt keep the message from being delivered but did prevent the proper parsing of the header. This disabled a mechanism for detecting that a newsgroup message had already been delivered to a given site, resulting in an explosion of redundant deliveries that only ended when disk partitions filled and blocked any further traffic from being received. The point here, as made by one observer at the time, is that its pointless to say that a user or a client system should never give bad input to a service. A service must instead be able to handle any input that could conceivably reach it, safely at a minimum and preferably with grace.
“Most developers tend to write code that expects a particular set of inputs. When that doesnt happen, unpredictable results can and do occur. One really does need to code defensively and not optimistically,” wrote developer Steve Booth in response to last weeks column.
The second theme has long been explored in settings such as airliner flight decks, industrial plant control rooms and other places where an automatic system might suddenly fail and a human operator might need to retake control. The system needs to be automatic enough to be useful, in terms of reducing operator fatigue and letting the operator have more of a supervisory role, while also keeping the operator sufficiently in the loop to minimize the time required to reorient and resume low-level control when something goes wrong.
One way to meet both of these goals is to build systems that wait upon the convenience of the user, instead of imposing a strict sequence of operations that treats the user as a component—and a pretty dumb component at that. A note from developer Ted Varga compared the different approaches taken by point-of-sale systems at two different retail chains: at one, he wrote, “The new system is insulting and treats everyone like an idiot. For example, when a credit card is used, the customer must enter whether the card is for credit or debit. Regardless of the choice, the checker must also ask the customer whether the card is credit or debit. Since my card can be used for both, I have occasionally told the checker the wrong selection, which the checker then enters into the cash register. If the customers and checkers input does not match, the entire card entry must be restarted from the beginning.” The system, he said, “requires the customer to enter information and then questions whether or not the customer knows what they are doing.”
In contrast, he said, the other system “is the absolute minimum required to complete the transaction. The transaction can be started before checkout is complete and simply completed.” The system stays out of the way.
The third theme brings to mind a passage that Ive quoted before from Steven Levys 1984 book, “Hackers“: “Why should we limit computers to the lies people tell them through keyboards?” As I said in the July 2003 column hyperlinked from the preceding sentence, that challenge “has been addressed with massive investment in automating or streamlining data entry”—but we still do dumb things even in simple areas like defining a data entry field. “One of the biggest problems we have in building truthful applications is the underlying data storage and the assumptions people make,” observed Dave Berg, executive technology consultant at KAE Software LLC. “For example, its always irked me that database date fields (and most language date datatypes) require Month, Day, and Year. Yet when being asking someone their birthday, many people are reluctant to provide the year. Many times I may know the month and day of someones birthday or anniversary, but not the actual date. And theres no way to record this.”
Even if we do capture all of the relevant data, with or without costly and error-prone human entry, were still a long way from the kind of systems that we really need. “Just putting some Web services out there and shoving XML down the pipes does not cut it. You have to have a formal business model, collaboration basis, common industry information understanding—so that all participants understand their roles and responsibilities,” asserted David RR Webber, who held out the hope that the forthcoming Version 2 of the Business Process Specification Schema will allow developers “to formalize your business process steps, and associate rules and context with them and store that as XML. This is a pre-requisite for adaptive systems,” he said, adding that “Even if the system itself is dumb as muck, other components can add intelligence downstream, and monitor and track and provide alerts.”
Even if systems may—OK, will—never get as good as wed like them to be, we can at least do a better job of making it possible to improve them as we get smarter ourselves. That would be a big step.
Tell me what steps youd like to take at [email protected]