Systems Must Be Designed to Doubt

Opinion: Sensors, business rules and cultivated paranoia yield customer-facing apps that can cope with unfortunate events.

My son looked at the minuscule trunk of the rental car, then at our stack of luggage—made larger than usual by an extra suitcase full of Christmas gifts, on their way to their place below the tree at his grandparents house. Politely, but firmly, he said, "No way, Dad." And something was clearly wrong, because I knew that Id reserved a bigger car than this.

As it turned out, our car was actually in space A-3, not in C-3 where wed been directed. "Sorry, sir, the system had it wrong," the clerk apologized when I brought the problem to his attention. We got the right size car, but I wondered what would have happened if Id taken the smaller one without question or comment: Would the guard at the gate have seen that the license plate number wasnt the one on my contract? Or would he merely have confirmed that the contract was valid, and that the signature on it matched the one on my drivers license? And that the photo on the license matched my face?

Would he have gone through most of the motions of assurance, while missing a crucial connection between promise and fulfillment?

It seems to me that this is still the all-important question for the designers of customer-facing systems, and theres nothing like the press of holiday travel and online shopping workloads to reveal the gaps that still remain to be closed.

Id seen another example of this problem the day before, when a shipping services tracking site was still assuring me that a three-day shipment was on schedule for delivery on Dec. 24. This seemed implausible, since the site showed no record of any event along its journey since Dec. 22—when the package was still on the opposite coast from me. A phone call—you remember those, you wait on hold and then talk to an actual person?—elicited the information that severe weather had delayed many shipments, along with an apology that the site had not been updated to reflect this.

Whats the point, I feel bound to ask, of a tracking system that tells you everythings fine, unless someone specifically tells the system that somethings gone awry? Wouldnt it make sense to have an algorithm that knows, in general terms, that a package thats still in Kentucky this morning will not be getting to Los Angeles this afternoon?

It seems to me that both of these incidents reflect a common imperative for designers of next-generation systems. I give the shopping and travel industries full marks for making routine transactions much more convenient, and certainly much less labor-intensive, than they used to be. Online shopping? Excellent. Online rebates? A definite win. Online check-in and advance printing of airline boarding passes? Super, guys, very well done.

But what about building systems that dont take the normal routine for granted? What about building systems that dont merely repeat what theyve been told, but that ask semi-intelligent questions about whats going on around them? And that know an unbelievable answer when they hear it?

/zimages/3/28571.gifClick here to read a Peter Coffee column about the risks of focusing too closely on one aspect of a job.

We have the tools to build these systems, what a control theorist might call closed-loop systems because reality can come back and update the systems beliefs. When a car is parked on the rental lot, the same technology that enables a hands-free "smart key" can tell the dispatching system what space that car is in. When a shipment is expected in Los Angeles on Friday afternoon, a simple business rule can fire to ask if its been placed on a Los Angeles-area delivery truck by Friday morning. We dont need to develop new technology to do any of these things.

What we need to do, and I know that this is hard, is get over the idea that any of these technologies is about the reduction of cost. That only works in the short run. In the long run, technology has to improve service to the highest level that still leaves room to earn a reasonable rate of return while offering services at a competitive price.

Its tempting to do what weve always done, but do it online so that the customer now performs functions that used to be done by customer service personnel who actually had to be paid. Its tempting, but its not viable. When online systems lie to customers, or when errors in those systems waste the time of both customers and employees, then the negative good will that results is expensive.

Web services enable a wealth of customer-facing systems, but they also raise the bar for the level of reliability and self-knowledge that those systems must possess. Resolve in the new year to be a leader, not a follower, in that pursuit.

Tell me what youre doing to build compulsively truthful applications at

/zimages/3/28571.gifCheck out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.