Anthony M. Townsend - Smart Cities - Big Data, Civic Hackers, and the Quest for a New Utopia

Buggy

A few weeks later, I found myself wandering around the MIT campus in Cambridge, Massachusetts, with nary a thought about uncooperative toilets in mind. Strolling west from Kenmore Square, a few minutes later I came across the new home of the Broad Institute, a monolith of glass and steel that houses a billion-dollar center for research in genomic medicine. The street wall was tricked out with an enormous array of displays showing in real time the endless sequences of DNA base pairs being mapped by the machinery upstairs.

And then, out of the corner of my eye, I saw it. The Blue Screen of Death, as the alert displayed by Microsoft Windows following an operating-system crash is colloquially known. Forlorn, I looked through the glass at the lone panel. Instead of the stream of genetic discoveries, a meaningless string of hexadecimals stared back, indicating precisely where, deep in the core of some CPU, a lone miscomputation had occurred. Just where I had hoped to find historic fusion of human and machine intelligence, I’d found yet another bug.

The term “bug,” derived from the old Welsh bwg (pronounced “boog”), has long been used as slang for insects. But appropriation of the term to describe technical failings dates to the dawn of the telecommunications age. The first telegraphs invented in the 1840s used two wires, one to send and one to receive. In the 1870s, duplex telegraphs were developed, permitting messages to be sent simultaneously in both directions over a single wire. But sometimes stray signals would come down the line, which were said to be “bugs” or “buggy.”1 Thomas Edison himself used the expression in an 1878 letter to Puskas Tivadar, the Hungarian inventor who came up with the idea of a telephone exchange that allowed individual lines to be connected into a network for the first time. According to an early history of Edison’s own quadruplex, an improved telegraph that could send two signals in each direction, by 1890 the word had become common industry parlance.3

The first documented computer bug, however, was an actual insect. In September 1947, Navy researchers working with professors at Harvard University were running the Mark II Aiken Relay Calculator through its paces when it suddenly began to miscalculate. Tearing open the primitive electromechanical computer, they found a moth trapped between one of its relays. On a website maintained by Navy historians, you can still see a photograph of the page from the lab notebook where someone carefully taped the moth down, methodically adding an annotation: “First actual case of bug being found.”4 As legend has it, that person was Grace Hopper, a programmer who would go on to become an important leader in computer science. (Hopper’s biographer, however, disputes this was the first time “bug” was used to describe a malfunction in the early development of computers, arguing “it was clear the term was already in use.”)5

Since that day, bugs have become endemic in our digital world, the result of the enormous complexity and ruthless pace of modern engineering. But how will we experience bugs in the smart city? They could be as isolated as that faulty toilet or a crashed public screen. In 2007 a Washington Metro rail car caught fire after a power surge went unnoticed by buggy software designed to detect it.6 Temporarily downgrading back to the older, more reliable code took just twenty minutes per car while engineers methodically began testing and debugging.

But some bugs in city-scale systems will ripple across networks with potentially catastrophic consequences. A year before the DC Metro fire, a bug in the control software of San Francisco’s Bay Area Rapid Transit (BART) system forced a systemwide shutdown not just once, but three times over a seventy-two-hour period. More disconcerting is the fact that initial attempts to fix the faulty code actually made things worse. As an official investigation later found, “BART staff began immediately working to configure a backup system that would enable a faster recovery from any future software failure.” But two days after the first failure, “work on that backup system inadvertently contributed to the failure of a piece of hardware that, in turn, created the longest delay.” Thankfully, no one was injured by these subway shutdowns, but their economic impact was likely enormous—the economic toll of the two-and-a-half-day shutdown of New York’s subways during a 2005 strike was estimated at $1 billion.8

The troubles of automation in transit systems are a precursor to the kinds of problems we’re likely to see as we buy into smart cities. As disconcerting as today’s failures are, however, they are actually a benchmark for reliability. Current smart systems are painstakingly designed and extensively tested. They have multiple layers of fail-safes. With the urgency of urban problems increasing and the resources and will to deal with them in doubt, in the future many smart technologies will be thrown together under tight schedules and even tighter budgets. They will struggle to match this gold standard of reliability, with only a few short-lived, sporadic glitches each year.

The sheer size of city-scale smart systems comes with its own set of problems. Cities and their infrastructure are already the most complex structures humankind has ever created. Interweaving them with equally complex information processing can only multiply the opportunities for bugs and unanticipated interactions. As Kenneth Duda, a high-performance networking expert told the New York Times , “the great enemy is complexity, measured in lines of code, or interactions.”9 Ellen Ullman, a writer and former software developer, argues, “it is impossible to fully test any computer system. To think otherwise is to misunderstand what constitutes such a system. It is not a single body of code created entirely by one company. Rather, it is a collection of ‘modules plugged into one another.... The resulting system is a tangle of black boxes wired together that communicate through dimly explained ‘interfaces’ A programmer on one side of an interface can only hope that the programmer on the other side has gotten it right.”10

In his landmark 1984 study of technological disasters, Normal Accidents, sociologist Charles Perrow argued that in highly complex systems with many tightly linked elements, accidents are inevitable. What’s worse is that traditional approaches to reducing risk, such as warnings and alerts (or the installation of the backup recovery system in the BART incident), may actually introduce more complexity into systems and thereby increase risks. The Chernobyl nuclear disaster, for instance, was caused by an irreversible chain of events triggered during tests of a new reactor safety system. Perrow’s conclusion: “Most high-risk systems have some special characteristics, beyond their toxic or explosive or genetic dangers, that make accidents in them inevitable, even ‘normal.’ ”

Normal accidents will be ever-present in smart cities. Just as the rapid pace of urbanization has revealed shoddy construction practices, most notably in China’s notorious “tofu buildings,” hastily put together smart cities will have technological flaws created by designers’ and builders’ shortcuts. These hasty hacks threaten to make earlier design shortcuts like the Y2K bug seem small in comparison. Stemming from a trick commonly used to save memory in the early days of computing, by recording dates using only the last two digits of the year, Y2K was the biggest bug in history, prompting a worldwide effort to rewrite millions of lines of code in the late 1990s. Over the decades, there were plenty of opportunities to undo Y2K, but thousands of organizations chose to postpone the fix, which ended up costing over S300 billion worldwide when they finally got around to it. Bugs in the smart city will be more insidious, living inside lots of critical, interconnected systems. Sometimes there may be no way to anticipate the interdependencies. Who could have foreseen the massive traffic jam caused on US Interstate 80 when a bug in the system used to manage juror pools by Placer County, California, erroneously summoned twelve hundred people to report for duty on the same day in 2012?