Why is software so prone to bugs? Why are software products so often delayed, or even canceled? Is software development really hard, or are software developers just not that good at it? In The Problem with Software, Adam Barr — an industry insider — explains why there is so much bad software, and why academia doesn’t teach programmers what industry wants them to know.
Below read an excerpt from chapter 11 of Adam Barr’s The Problem with Software.
The Future
[Atul] Gawande’s book The Checklist Manifesto is subtitled How to Get Things Right. At one point he talks to a structural engineer about how the construction industry has changed:
For most of modern history, he explained, going back to medieval times, the dominant way people put up buildings was by going out and hiring Master Builders who designed them, engineered them, and oversaw construction from start to finish…But by the middle of the twentieth century the Master Builders were dead and gone. The variety and sophistication of advancements in every stage of the construction process had overwhelmed the ability of any individual to master them.[5]
Today’s software engineers are master builders, and they are in danger of being overwhelmed.
Gawande also discusses the hero test pilots from the early days of high-speed aircraft, as documented in Tom Wolfe’s book The Right Stuff. They succeeded through improvisation and daring, but eventually “values of safety and conscientiousness prevailed, and the rock star status of the test pilots was gone.”[6] The universe applies a natural corrective to test pilots who fail to adapt, but no such effect exists in software; the middle and upper management of software companies are full of successful self-taught programmers. Hopefully, more recent graduates have heard about design patterns and unit tests; while those are a long way from providing a scientific basis for software engineering, at least they have opened people’s eyes to the fact that accepted knowledge is possible in the software industry, which in turn should make them more amenable to learning new ways if we can discover them. But of course they do have to be discovered first.
Otherwise, we will have to confront another quote from Gawande’s book:
For nearly all of history, people’s lives have been governed primarily by ignorance…Failures of ignorance we can forgive. If the knowledge of the best thing to do in a given situation does not exist, we are happy to have people simply make their best effort. But if the knowledge exists and is not applied correctly, it is difficult not to be infuriated…It is not for nothing that philosophers gave these failures so unmerciful a name — ineptitude.[7]
Are programmers inept? I don’t think they are in the exact way Gawande indicts medicine, the prime focus of his book. He is talking about situations in which the knowledge of how to deliver proper medical care is unquestionably available and agreed on by all involved, but for various reasons is not applied properly. Gawande sees parallels to this struggle in “almost any endeavor requiring mastery of complexity and of large amounts of knowledge” — a list that to him includes foreign intelligence failures, tottering banks, and (little does he know) flawed software design.[8]
The argument against labeling programmers inept is that they have not even reached the stage of knowing the right way to do their jobs. That’s because they have stopped trying to figure this out, which isn’t a great defense: we are still inept, just in a slightly different way.
In 1986, [Frederick P.] Brooks wrote an essay titled, “No Silver Bullet” — a reference to the ammunition reputedly needed to kill werewolves. “We hear desperate cries for a silver bullet, something to make software costs drop as rapidly as computer hardware costs do,” he lamented,
But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement in productivity, in reliability, in simplicity…Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any.[9]
Brooks describes what he feels is the essence of the problem, the inherent difficulties of software: complexity, conformity (the need to fit new code into an existing API), changeability, and invisibility (the difficulty of visualizing the internals). He lists various developments that may help, including object-oriented programming (which at that time was just beginning its transformation into Object-Oriented Silver Bullet Amalgamated Holdings), but doubts that any of them will supply the magic needed.
Nine years later, almost at the end of the time period he was considering in the original paper, Brooks produced a follow-up essay “‘No Silver Bullet’ Refired,” discussing reactions to the original. He wrote, “Most of these attack the central argument that there is no magical solution, and my clear opinion that there cannot be one. Most agree with the arguments in ‘NSB,’ but then go on to assert that there is indeed a silver bullet for the software beast, which the author has invented.”[10] The italics are mine, because I can think of no more succinct summary of the ongoing procession of alleged software panaceas.
Brooks ends his second essay with a short section titled “Net on Bullets — Position Unchanged.” He quotes noted software observer Robert Glass, in an essay in System Development magazine: “At last, we can focus on something a little more viable than pie in the sky. Now, perhaps, we can get on with the incremental improvements to software productivity that are possible, rather than waiting for the breakthroughs that are not likely to come.”[11]
The history of software engineering has been a search for the silver bullet. Structured programming, formal testing, object-oriented languages, design patterns, Agile methodologies — all are useful, but none alone can slay the werewolf. I personally lived through all these transitions, even structured programming; due to spending my early years in a self-taught bubble of Fortran and BASIC, I was able to experience the twilight of GOTOs firsthand, ten years later than the rest of the industry. Each of these started out small, gained supporters, and wound up being hyped as the solution to all programming problems, leading to inevitable disappointment and disillusionment. I can understand why programmers hope beyond hope for the silver bullet and have eagerly glommed on to a succession of shiny objects. “Any port in a storm,” as the saying goes. Unfortunately, as Parnas put it, “[Programmers] have been fed so many ‘silver bullets’ that they don’t believe anything anymore.”[12]
Moreover, the software industry has gotten in the habit of abandoning old silver bullets once they get tarnished. It’s a binary view of the world: a programming technique is either going to solve every problem or it’s useless. When Microsoft began hiring software test engineers to test the software, the developers, who previously had been responsible for this, quickly segued into “throw it over the wall to test” mode. In the mid-2000s, Microsoft replaced software test engineers with software design engineers in test, responsible for writing automated tests, and stopped relying on manual testing. With the later move to unit tests, which are written by developers, the company got rid of a lot of the software design engineers in test and the user-interface-level tests that they provided. Now with the transition to the cloud, there is an emphasis on “test in production,” where updates to the software are quickly deployed to a small percentage of real customers, with checks in place to quickly detect problems and roll back the update. Each new technique is useful, but it should be viewed as another arrow in the quiver, not the be-all and end-all that obviates the need for what went before.
