Stupid Publisher Tricks: My So-Called (Digital) Life
Jerry Laiserin

Investigators into a recent mid-air collision over Germany reportedly suspect the proximate cause may have been a pilot's choice to ignore instructions from his craft's collision-avoidance computer in favor of contrary advice from a (human) air-traffic controller. Rarely are folks in AEC, plant/process, and infrastructure industries faced with such immediate life or death consequences; nevertheless, we still need to evaluate our relative faith in computer output versus human judgment before signing and sealing computer-aided design documentation, or relying on such data.

In IssueSix's Laiserin'sLemma, "Computer-Aided Mistakes," I looked at the potential for "standard of care risk" through "over-reliance on new and unproven technology or unquestioning reliance on technology that automates away some aspect of professional judgment." It's important to bear in mind that I was not and am not arguing against technology, just arguing for due diligence in its use. Some systems are well-proven, while others are not yet ready for prime time. Whether we are producers of digital design data (architects, engineers, specifiers, and so on) or consumers of that data (contractors, owner/operators, facility managers, and the like), it's our job to understand and, if necessary, manage around the relative reliability of the systems used to create and manage our data.

However, there's a natural tendency to ride the pendulum to an inverse problem—unwillingness to trust any "advice" generated by a computer. Even if we don't read science-fiction, we intuitively recognize that our real-world computers are not endowed with the rudimentary fail-safe mechanisms first proposed by Isaac Asimov sixty years ago(!) as "Laws of Robotics."

> The First Law of Robotics: "A robot may not injure a human being, or, through inaction, allow a human being to come to harm."
> The Second Law of Robotics: "A robot must obey the orders given it by human beings except where such orders would conflict with the First Law."
> The Third Law of Robotics: "A robot must protect his own existence as long as such protection does not conflict with the First or Second Laws."

Asimov first published these "laws" in a 1942 short story (subsequently collected in his classic tome, I, Robot). Our software violates Asimov's First Law all the time, especially allowing us to come to harm through its inaction; while even our most sophisticated programs blindly obey the first half of the Second Law, blithely ignoring the second half. Tell your latest parametric whiz-bang to constrain all exit corridors at some unlawfully and dangerously narrow width, and it may merrily propagate the harm throughout every nook and cranny of your project. The Third Law? We all have software that routinely fails to protect its own existence, despite the fact that such crashes harm us and our work.

Maybe we should revive a mantra from Cold War-era nuclear politics: "Trust, but verify." Implement sufficient verification procedures, such as human "walk-throughs" of project documents, to define a rational level of trust in your systems. Until proven otherwise, assume that safe use of any automated procedure, from email to hyperlinked specifications, requires redundancy—parallel systems, backups, and standbys for the backups.

Here's the stupid publisher's trick. Traveling 120-150 days and 120,000-150,000 miles each year, I rarely leave home without a certain famous charge card. I use the same card for automatic payments of recurring charges, such as my mobile phone bill. A few weeks ago, the card company's computers thought they detected a pattern of potentially fraudulent charges. Because American consumers generally are not liable for more than the first US$50 of such charges, the company's computers appear to be programmed to protect themselves via trigger-happy response to the slightest hint of unauthorized transactions. The card in my possession was canceled and a new account number issued—mailed to my home, where it waited with all the other held mail until I returned from what became a nightmare trip. As I arrived in each successive city on this long journey, I found my car rental and hotel reservations erased from their respective computer systems as they attempted to tap into my now invalid account number. In protecting themselves, these computers allowed harm to come to me in direct contradiction to the expectations of Asimov's Laws. In the end, not a single penny of fraudulent or suspicious transactions ever appeared on my statement—before, during, or after this computer-triggered episode—an episode that could easily have been avoided by one phone call from one human employee of the card issuing company.

My "injuries" were mostly in the form of inconveniences, but suppose a similar farce was acted out in a highway construction supply chain, with equipment orders canceled and material deliveries rerouted because of e-commerce errors blindly cascading through networks of computers spanning multiple enterprises. How many software vendors or e-commerce service providers would be liable for the resulting delay claims and liquidated damages? (hint: starts with "Z" and rhymes with "Nero").

Today, I carry an extra charge card (from a different issuer) that I never use; it's just for backup. Ditto for a third card (from yet another issuer) to which my automatic monthly bill payments are charged, isolated from all other transactions. Your errors and omissions insurance carrier or bonding company likely recommends that you print and save a copy of every addendum or request for information that you transmit electronically, for much the same reasons I now sport those redundant charge cards—to preserve our so-called digital lives from disruption by our "lawless" computers.

Postscript: The lone bright spot in my saga of computerized inconvenience, was a sharp outfit called J2 Global Communications, Inc. I use their JConnect email-based fax service, but the same account entitles me to single in-box voicemail, faxing, and email, plus affordable conference calling and a lot more. J2 was the only outfit to gracefully and graciously recover from the computer billing glitch propagated to them by others, restoring my service perfectly. Any individual or company seeking streamlined and integrated messaging services should check out J2.
JL



< back