|Homepage / Publications & Opinion / Silicon.com
Time to stamp out costly typos
Where's the common-sense code to cut out fat-fingered mistakes?
Written in Washington DC and dispatched to silicon.com from a coffee shop in Pentagon City via a free wi-fi service.
Typos have been with us since we first scribed characters on clay tablets but only recently have they posed an immediate threat to world stability.
Look down at your keyboard and notice the distance between the B and the M. There is only N between them. So it isn't hard to imagine how someone might inadvertently brush the B instead of the M. And it must happen thousands of times per day across the planet, along with other typos. Does this design issue cause significant problems other than mild inconvenience? Mostly not.
Last week was an exception. A New York trader apparently made a simple B-for-M slip that led to a 1,000-point crash in the market. In the aftermath, the media blamed the machines for the automatic-trading stampede that ensued. Pundits have also been discussing the simmering threat of more of these types of events in the future. But guess who wrote the software and built the machines? We did.
Why wasn't there a simple line or two of common-sense software to ask the question: is this trade reasonable, and does the organisation involved have the funds to complete? You might think a last-second question or tick box would also be mandatory: "Please check this transaction one more time."
With any luck, someone is creating that code right now, because this kind of error is bound to happen again, and worse, some rogue agent dedicated to generating private wealth could exploit it for personal gain.
How can keyboard slips be allowed to cause such catastrophic problems? (Photo credit: Shutterstock)
Have these trader errors happened before? Yes, indeed. They are commonly called fat finger trades. And have such errors occurred in other domains? Yes, and in a very big way. Defence and civil systems have been brought down by keying errors. Fortunately, downtime has been the only significant consequence to date, but it is easy to imagine how the outcome could be much worse.
As we become increasingly dependent on machines that assume more human functions, with far higher degrees of network connectivity, we must assume a greater degree of design responsibility from the outset. We really have to become more dedicated in our testing regimes and trials before commercial release.
Another worry, and paradoxically, perhaps our salvation, is that machines are getting smarter and writing more code. But unlike us they make far fewer mistakes, don't get tired or distracted and, as yet, are not foolish or devious.