Why is it so difficult to build correct software

It gets at something fundamental. What is it that makes software safety so hard? I would say that responses to the comic have fallen into two big groups: Software safety is really hard because we have adversaries. The comic is needlessly nihilistic about software safety. Namely: Software is leaner. Software is moves faster. Software is more complex. Consequences for adversaries are lower. Software is Leaner At Akamai, we had a team of 4 people who reviewed about 50 incidents a year for a company of 6, people, part time around other responsibilities related to managing the incident process.

Software Moves Faster At Akamai, the Infosec design safety review team of four to eight people reviewed about 50 new systems a year. Consequences for Adversaries are Lower In order to successfully hijack a plane, an attacker needs to run a very real risk of death or being arrested.

Software Needs a Safety Culture The Wright brothers were more or less two guys in their garage, who flew the first airplane at Kitty Hawk in To an extent one simply has to learn from experience. But having a clearer picture of software development will help us better appreciate the sources of risk in software development and avoid misunderstandings.

Given how abstract software development is, it can be tempting to fall back on analogies to more concrete disciplines. Especially tempting is an analogy to construction or physical engineering. This analogy has historically influenced software project management methodology especially on the waterfall model. But we should be cautious about this:. As Fowler points out, it is dangerous to think we know in advance how to approach a problem without building anything first.

It is also dangerous to think we know in advance what the tools are and this is another disadvantage of the construction metaphor. Contemporary commercial development relies a lot on existing tools and libraries which have to be chosen. These choices are important as it may be difficult to make a tool work for a particular purpose.

Construction does also involve certain problems of tool selection. For example one has to choose types of brick or material for load-bearing and durability.

The difference with software is the tools themselves are conceptual so the boundaries of what they do are harder to see. Unchallenged early assumptions about tools can lead to overruns and contribute to failures. But the big risk is unchallenged assumptions in the business objectives. There is scope for mistaken assumptions to slip through about whether a building design provides enough space for the number of people who will use it and whether there are enough elevators.

But visual plans help to bring out assumptions. Since software is abstract by nature it is difficult to make it concrete enough to flush out assumptions without entirely building the solution by which point all the cost has been incurred. Refining problem specifications to flush out assumptions can be more art than science. Refining specifications and choosing tools to address them are both central to what software developers do. Risk is inherent to both. Software development is both logical and creative and therein lies its chaos.

Creative problem-solving can serve as a good metaphor for commercial software development. We can see this by considering a particular story of puzzle-solving from the old Norse saga of Ragnar Lodbrok. He commands her to arrive neither dressed nor undressed, neither hungry nor full, and neither alone nor in company.

Kraka is up to the challenge and arrives draped in a net and her long hair, biting an onion, and with only her dog as a companion. Ragnar is impressed and Kraka and Ragnar get married. Image from Ancient History Encyclopedia. Ragnar does not entirely know what will satisfy his request until he sees it. He knows certain constraints that will need to be met but he will have no idea that the solution Kraka finds is a possible solution until he sees it. To see the connection more clearly, let us imagine that Ragnar does not immediately marry Kraka.

Instead he next specifies that Kraka should first prove her worth in an even more heroic exercise. He asks her to produce a system which will process the documentation approvals and rejections for which he currently employs a whole team.

At the point of specification, Ragnar has little conception of how that task might be achieved without the need for a team. Much as with his previous riddle, Ragnar does not know it could be possible to process the documentations approval and rejections without a team. In comparison the software industry is only about 50 years old.

We still have a long way to go before we have the body of experience behind us that the construction and manufacturing industries have.

Today the construction industry use mostly prefabricated materials and parts. Most of these are made by machine and have been tried and tested on many other projects.

Software systems are fundamentally built by a process of discovery, invention, and creation of new components with the result that each new system is a custom project created from scratch. This leads us to our next point. Because all new projects are custom built it follows that every line of code is unproven and therefore should be tested. However, in the real world, this is totally impractical. Each line of code will have dozens, even thousands, of possible inputs, outputs, states or dependencies to deal with.

It can impact, or be impacted by, other lines of code or by external factors. And testing a single line of code is only part of the challenge. No line of code exists on its own. It is part of the whole system and the whole needs to be tested to ensure that all parts of the application function correctly.

The sheer complexity of software means it is impossible to test every path so in the real world the best project teams will implement processes that are designed to increase the likelihood of the software being defect free. They will use techniques such as coding standards, unit testing, smoke testing, automated regression testing, design and code reviews etc.

All of this testing comes at a cost. The question to be answered on every project is — how critical is this software and how much testing should we do to ensure the software is correct?

Too often the testing phase is rushed and the software goes out with an unacceptable level of defects. On the other hand, for most systems there are diminishing returns for extending the testing past a certain point. There comes a point with all software where the value of getting the software released is greater than the value gained by continuing to test for defects.

This is why most commercial software gets released even though it is known to contain defects. For over 10 years the research company, The Standish Group, have surveyed companies about their IT projects. The No. Without the involvement and input of a user representative the project is doomed to failure.

This person should be a subject domain expert with the authority to make decisions and a commitment to the project timescales.

So assuming there is good user input then the challenge of translating requirements into a design begins. And this is no easy task as our next point shows. Even with good input from the users no amount of analysis of user requirements can take away an immutable fact that users only think that they know what they want. It usually starts once the first designs begin to appear which cause the users to think more deeply about what they really want.

There is no simple answer to this dilemma despite the fact that various techniques, such as Agile development, have evolved to make it easier to adapt to changing requirements. Even seemingly small changes can have a big impact on a project. Each explicit requirement can lead to many more implicit requirements by a factor of up to 50 further complicating the software.

Changing requirements during the development phase is one of the great challenges facing all software developers. There is one argument that states that software development is so hard because programming is so easy.

In other words it is relatively easy to learn how to write code but there is a huge gap between that and delivering great software. Some software companies are responding to these criticisms by revamping their procedures; Microsoft, stung by charges that its products are buggy, is publicly leading the way.

Yet problems with software quality have endured so long, and seem so intractably embedded in software culture, that some coders are beginning to think the unthinkable. To their own amazement, these people have found themselves wondering if the real problem with software is that not enough lawyers are involved.

Microsoft released Windows XP on Oct. That same day, in what may be a record, the company posted 18 megabytes of patches on its Web site: bug fixes, compatibility updates, and enhancements. Two patches fixed important security holes. Microsoft advised and still advises users to back up critical files before installing the patches.

Buyers of the home version of Windows XP, however, discovered that the system provided no way to restore these backup files if things went awry. Downes of Radsoft, a software consulting firm. Or rather, its lack of design. Simply placing the cursor over the Visual Studio window, Downes has found, invisibly barrages the central processing unit with thousands of unnecessary messages, even though the program is not doing anything.

Importantly, compilers refuse to compile code with obvious problems-they spit out error messages instead. Until the s, compilers sat on large mainframes that were often booked days or weeks in advance. Not wanting errors to cause delay, coders-who in the early days tended to be trained as mathematicians or physicists-stayed late in their offices exhaustively checking their work.

Writing software was much like writing scientific papers. Rigor, documentation and peer-review vetting were the custom. But as computers became widespread, attitudes changed.

Instead of meticulously planning code, programmers stayed up in caffeinated all-night hacking sessions, constantly bouncing results off the compiler. Again and again, the compiler would spit back error messages; the programmers would fix the mistakes one by one until the software compiled properly. On average, professional coders make to errors in every thousand lines of code they write, according to a multiyear study of 13, programs by Humphrey of Carnegie Mellon.

Most would have been too small to have any effect, but some-many thousands-would have caused serious problems.