What Should We Do to Prevent Software from Failing?
The analogy between software &quot;engineering&quot; and structural engineering is used a lot to point out the failures of software. I think this analogy is a category mistake caused entirely by the misapplication of the word &quot;engineer&quot; to software developers.<p>We have already solved large areas of common classes of bugs at the language level, through strong static typing, memory safety and safe concurrency (Rust is the vanguard here but there are lots of languages that tackle these problems in effective ways).<p>Institutional inertia (technical debt) is the only reason why we can&#x27;t apply these solutions to <i>all</i> software. I work on a PHP app with code that goes back 15 years. To convert it to rust we&#x27;d have to invest basically the same as the operating cost of the company. That&#x27;ll never happen.<p>Once &quot;safe&quot; languages are used, there are still bugs of course. But what are those bugs? Failures of thought, plain and simple. Structural engineers work within the limits of physical reality and these constraints greatly limit the range of possible creation, thus also the range of possible failure.<p>Software has limits too, in memory, storage and processing capacity. But otherwise it works entirely in the realm of pure thought.<p>Well defined specifications that can be turned into concrete tests can solve a lot of these problems, too. (But this is also very expensive).<p>But even if you have specs and tests, there is no magic formula for ensuring your ideas are always sound. If the idea is wrong you can&#x27;t even write tests to ensure it&#x27;s correct. &quot;Correctly&quot; functioning components can have complex, difficult to predict side-effects when composed into complex systems.<p>We do have everything we need to write highly reliable software. But solving the software failure problem is the same task as solving the erroneous thinking problem. I don&#x27;t know that we meat-sacks can &quot;solve&quot; that problem.