Opinion: Allowance for idiocy, engagement of users, and improved process smarts are readers' recommendations.
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."
Click here to read Peter Coffees Jan. 3 column on grid computing.
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 peter_coffee@ziffdavis.com
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.
Application Development 
