It's been said that software is "eating the world." More and more, critical systems that were once controlled mechanically, or by people, are coming to depend on code. This was perhaps never clearer than in the summer of 2015, when on a single day, United Airlines grounded its fleet because of a problem with its departure-management system; trading was suspended on the New York Stock Exchange after an upgrade; the front page of The Wall Street Journal's website crashed; and Seattle's 911 system went down. The simultaneous failure of so many software systems smelled at first of a coordinated cyberattack. Almost more frightening was the realization, late in the day, that it was just a coincidence. Software is special. Just by editing the text in a file somewhere, the same hunk of silicon can become an autopilot or an inventory-control system. This flexibility is software's miracle, and its curse. Because it can be changed cheaply, software is constantly changed; and because it's unmoored from anything physical, a program that is a thousand times more complex than another takes up the same actual space: it tends to grow without bound. "The problem," says Nancy Leveson, "is that we are attempting to build systems that are beyond our ability to intellectually manage." This is the trouble with making things out of code, as opposed to something physical: "The complexity is invisible to the eye." When you press your foot down on your car's accelerator, for instance, you're no longer controlling anything directly; there's no mechanical link from the pedal to the throttle. Instead, you're issuing a command to a piece of software that decides how much air to give the engine. The car is a computer you can sit inside of. The steering wheel and pedals might as well be keyboard keys. Software has enabled us to make the most intricate machines that have ever existed. And yet we have hardly noticed, because all of that complexity is packed into tiny silicon chips as millions and millions of lines of code. But just because we can't see the complexity doesn't mean that it has gone away. While Chris Granger was at Microsoft, he arranged an end-to-end study of Visual Studio, the only one that had ever been done. The findings surprised him. "Visual Studio is one of the single largest pieces of software in the world," he said. "It's over 55 million lines of code. And one of the things that I found out in this study is more than 98 percent of it is completely irrelevant." [James Somers (2017), The Atlantic]
In the past 10 years, at least $2.5 trillion has been spent trying to replace legacy IT systems, of which some seven hundred and twenty billion dollars was utterly wasted on failed replacement efforts. Just how big a problem is this? The size of the problem really is unknown. We have no clear count of the number of systems that are legacy in government where we should be able to have a pretty good idea. We also have really no insight into what's happening in industry. In fact, a recent report by the Social Security Administration's Inspector General basically said that even they could not figure out how many systems were actually legacy in Social Security. A few years ago, a Bloomberg article noted that every mile of fresh new road will one day become a mile of crumbling old road that needs additional attention. Less than half of all road budgets go to maintenance. Do we see the same thing in IT? Do we keep building new systems, seemingly without a second thought that we're going to have to maintain them? Yes, and for good reason. When we build a system and it actually works, it works usually for a fairly long time. The irony is that the longer these systems live, the harder they are to replace. Paradoxically, because they're so important, they also don't receive any attention in terms of spend. Typically, for every dollar that's spent on developing a system, there's somewhere between eight and 10 dollars that's being spent to maintain it over its life. But very few systems actually are retired before their time. Almost every system that I know of, of any size tends to last a lot longer than what the designers ever intended. It's easier to build new systems, so there's money to build new systems, and that's what we we constantly do. So we're building new IT systems over time, which has again, proliferated the number of systems that we need to maintain. The other aspect is, as we build these systems, we don't build them a standalone systems. These systems are interconnected with others. And so when you interconnect lots of different systems, you're not maintaining just an individual, you're maintaining this system of systems. And that becomes more costly. Because the systems are interconnected, and because they are very costly to replace, we tend to hold onto these systems longer. And the probability of failure is also huge. We're starting to see the realization that IT, which at one time—again, systems designers were always thinking about 10 years is great, twenty years is fantastic—that maybe now that these system's, core systems, may be around for one hundred years. [Steven Cherry and Bob Charette (2020), IEEE Spectrum]
Comments
Post a Comment