Users Wont Pay For Quality Software

For purposes of this discussion, the word "quality" roughly means "lack of defects".

Face it. The software you buy at the store is buggy. Companies hide behind "we aren't responsible for anything" clauses in their license agreements. Compared to most other goods, software has an unacceptably large number of design defects.

How many patches have you applied? How many has your computer applied to itself? My Ubuntu system applies several patches a week. In any other field, a "patch" is called a "recall".

How do we get away with it?

Because users are addicted to features. People want to get the latest features now. Look at cell phones -- we have cameras on our phones, and it's almost impossible to get a phone without a camera. My MP3 player comes with games.

And the people are willing to pay. Not only in dollars, but in bugs.

We can build high-quality, bug-free systems. But they're expensive, much more expensive than normal software. You have the computer that decided whether to deploy an airbag, and how hard. You have fly-by-wire. You have surgical robots. You have pacemakers and defibrillators. Bugs in these systems are simply unacceptable. I can only imagine that these are designed by licensed engineers with personal liability involved with the project.

It's amazing how that slows down a project, isn't it?

It's a twist on the eighty-twenty rule. As quality rises asymptotically towards perfection (one), the effort required goes up dramatically.

Personally, if I'm writing a one-shot script quickly, I achieve one nine of quality: 90% of what I release works properly. If I work harder at it, I can personally achieve a second nine: 99% reliability. With a host of UnitTests and other tests, I can achieve three to five nines of reliability: 99.9% to 99.999%

I can't get seven or eight nines of reliability: I would need months if not years of professional training for that. And it would take forever. Sure, with the right training, team and talent, I might be able to help a team bang out a defibrillator within a year or so. But a word processor?

Imagine a dev team, any size you like, working to recreate a modern-day word processor with eight nines of reliability. It would release something that looks like a 2009 word processor sometime in the 2060s. And the result wouldn't be a media download, it would be a standalone piece of hardware with an embedded UPS. A program is no more reliable than the levels below it: OS, hardware, power supply. And you know that if you release your software simply as software, some people are going to run your eight nines reliable system on a hacked-to-Hell pirate copy of a HappyCo? OS running on a machine with a genuine hard drive from Crazy Goober's Hard Drive and Pottery Wheel factory in a place where the power fluctuates between 94 and 137 volts and come crying to you because they lost their data on your "reliable" word processor when the computer starts emitting blue smoke.

People aren't willing to wait that long. They want their 2009 word processor in 2009, and if it eats their work once in a while, that's the price for not processing their words with ED and TROFF on Hollerith cards. Unless the system really needs to be as reliable as a bridge (which, I guess, takes nine nines reliability so that tens of millions of cars can go over it safely), they're willing to let us spend our time putting features in rather than removing every possible failure mode.

--RobMandeville

We can build high-quality, bug-free systems.

I COMPLETELY disagree with this

[As do I. But I think we can build high quality systems with two to three orders of magnitude fewer bugs and regressions than we currently see. I.e. two or three more `nines`. We would need to change our tools, our languages, and our idioms to make it happen - statically checked assertions (via automatic test generation and symbolic analysis), dependent typing, linear typing, concurrency models that trade performance for consistency. There are efforts to make these practical for general purpose programming, web programming, even low-level OS programming - cf. Eiffel, Idris, ATS, F*. But most industry programmers never hear of them.]