Why software will never be bugless

Friday June 17, 2016 , 4 min Read

The expectation of people with regard to software quality is profoundly unrealistic. It could be because they depend so much on software that anything less than perfect is ‘un-acceptable’.

The complexity of software is vastly underestimated. To begin with no software programme ever runs in isolation, which is why all programmes are susceptible to bugs that exist in the underlying components or may be interactions among components. While operating systems tend to be fairly stable, other software pieces like libraries, plugins, and drivers have yet not achieved high level of reliability. Now add to this hardware, CPU interruptions, stack overflows, RAM limitations, etc. Things go from hard to impossible when we bring Internet and distributed programming in the picture. Internet is not perfect, CPU's are not perfect, databases are not perfect either, none of the computer components were ever designed to be perfect; instead they are designed to be "Good Enough". Even a perfect programme will eventually fail due to a hiccup by the machine. There's nothing we can do to stop it.

For simplicity let’s consider a programme as common as the implementation of binary search. Now the most popular algorithm of binary search that was even part of the standard Java library and the same code was used across the globe had a bug that went undetected for around 20 years [Java Bug Id: JDK-6412541]. Now if just 20 lines of code that are widely used and even supposedly proven correct take 20 years to get bug-free, how can we really expect a common programme to be bug-free?

Have we ever thought how many bugs are present in a common programme? One of the most reasonable number I found was "10 defects per 1000 lines" [Code Complete, 2nd edition, Page 517]. Now that gives us around 40,000 to 50,000 bugs in our software of reasonable scope and size. Thus, even if we could find and solve 90 percent of all bugs (using the latest in testing technologies like code reviews, automation testing, etc.) that'd be incredible. And yet we'd still have around 5,000 bugs in the software.

Although in theory it seems possible to write a bug-free programme, doing so would be very expensive. In a system of the decent size and scope that is under discussion here, this is practically ‘IMPOSSIBLE’. It might take us another 40‑50 years to write such a 'bug-free' system. And to write a system to prove it would take exponentially more time as we would have to come up with every possible use case and write a system that would test each one. Moreover, to do this you need programmers who have extensive knowledge of logic, math, and especially reasoning. And these kind of programmers come at a very high cost, as most software developers out their either aren't smart enough to learn or simply don't care. Or more often, they're on a deadline. Add to this the time scheduling of software projects, which due to its intangible nature often requires a lot of guesswork. When deadlines loom and the crunch comes, mistakes will be made.

Considering all these complications, costs, and hugeness of the software, a typical customer is more happy with a cheap software which works well 99 percent of the time (and 99.99 percent of the time after installing additional updates) than to have perhaps a thousand times more expensive software which works well 100 percent of the time. Also, the customer wants to have this software now, and not in 10 or 20 years.

Because a software with a bug is better than no software at all, and this is exactly how the other industries work, pharmaceutical companies all over the globe sell medicines with known side-effects and all science universities all over the world teach Newtonian physics, although it has known limitations. This is why having a solution with known deficiencies is much better than having no solution at all, or rather having a solution with unknown deficiencies. And as software developers we always strive to hit the optimal combination where the bugs are not too frequent and not too serious, and the production is fast and cheap enough. This is the proven combination that brings customer happiness and business growth.

The case is not that the we should not expect best quality softwares, rather the idea is that we have to accept bugs as a natural byproduct of cutting edge design and development. We also have to accept bugs as part of the overall software picture if we want ultra-modern software applications within a reasonable time frame.