Learn From What Works in Paper-Based Systems

Opinion: It's easy to "improve" a manual process in ways that lead to new kinds of errors.

I had an opportunity last week to observe a transition, still in progress, from paper-based record keeping to an online operation. The new system was vastly superior when everything—and crucially, everyone—was behaving according to specifications. Its important to remember, though, the dictum of "Systemantics" satirist John Gall, whose "Systems Bible" includes the warning: "Any large system is going to be operating most of the time in failure mode."

I was one of the adult leaders taking a group of 32 Boy Scouts to a week of summer camp, where we found that the "Blue Cards" used by generations of Scouts to track their fulfillment of merit badge requirements had been replaced by a Web-accessible database. One unintended consequence of this change was that adult Scout leaders now had to resist—often unsuccessfully—the temptation to check their e-mail, as long as they were logged on to the system to update Scouts records anyway. So much for getting away from everything.

The major problem arose at the end of the week, when Scouts who had attended a class—but not correctly signed up for it—received badge completion reports that did not show their work. I suspect that the system simply did not ask the counselors for input on Scouts that the system didnt know were there. Crucially, I saw the clipboard of one counselor, who had added hand-written rows of names and data to his class roster printout and had carefully tracked the progress of his "phantom" Scouts. When asked, he was therefore able to confirm that they were there and had done the work. There was even a stack of little cards prepared that counselors could use to file late corrections to the office so that oversights like this—once noticed—could be fixed.

With the old Blue Card system, though, this simply wasnt an issue: a Scout showed up at his first class with his Blue Card, which the Counselor then held for the week while adding requirement completion information—and then turned in to the office, effectively combining the sign-up and the completion report in a single operation.

The Blue Cards, one might say, were an object-oriented system: The data structure followed the flow of the work and arrived at the end in one piece instead of requiring assembly from several pieces in several different places. With the Blue Cards, moreover, an incomplete class roster would find itself at the end of the week sitting side-by-side with cards—physical objects, difficult to ignore—that did not correspond to roster entries. The system would send, in effect, a tangible signal of a problem.

As I said, the new online system had a lot of advantages. I could export sign-up information to Excel and sort by Scout, or by time of day, or by class. I was able to arrive at camp with printouts that told me, at any given time, which Scouts should be where. The system knew which badges were offered during which sessions of the camp day, and would not allow a Scout to prepare an impossible schedule. Overall, it was a definite improvement, and I commend those who are making the effort to streamline summer camps classic but cumbersome systems.

Remember Galls warning, though, that systems are rarely working entirely as they were designed, and his corollary (borrowed from family therapist Virginia Satir) that "Problems are not the problem: coping is the problem." Gall further offers the Unawareness Theorem, phrased as the question: "If youre not aware that you have a problem, how can you call for help?" Both of these statements are important warnings to application developers.

Dont merely build a system to work correctly; build a system to fail, when it does fail, both gracefully and also loudly. That is, the system should do as much as it can, rather than collapsing completely, but it should also be designed to anticipate and clearly signal likely failure modes.

A system, in short, should be trustworthy, loyal, helpful, friendly, courteous… Oh. Right. I thought that sounded familiar. Application builders, like Boy Scouts, should be prepared.

Tell me how you build your systems to do a good turn daily at peter_coffee@ziffdavis.com


Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.