What is good-enough software?

published: Tue, 8-Mar-2005   |   updated: Thu, 27-Oct-2005

(I wrote this for an internal discussion we've been having on writing software that's "good enough". To many, the term seems tainted so I wanted to redress the balance.)

The problem with the term "good enough software" is that it seems to have a slightly grubby connection: software that's just good enough to pass muster. It isn't polished, it isn't clean, perhaps it isn't even maintainable (a one-off program, for example).

The opposite of good enough software is bug-free software. I would venture that it is this term that should be viewed as highly dubious.

What is bug-free software? It certainly isn't software that has zero bugs. It's merely software that we have shown through testing to have no bugs that we can see. Nothing more and nothing less. There could be (and probably will be) several bugs in the application: it's just that we haven't managed to devise a test that reveals them. After all it's easier to prove the presence of something than to prove the absence of something (perhaps we haven't tried hard enough).

So, bug-free software doesn't exist. Instead we have "software that doesn't have the bugs we tested for". Perhaps it should be "mostly- bug-free software".

Now view this from a slightly looser context. Perhaps our testing will reveal bugs that only affect a certain percentage of our users. If that percentage is considerable, say in the ten of a percent, we're going to get nailed on it. Our software isn't good enough so we should fix the bug.

If the percentage of our users that would encounter the bug is small (perhaps the user must be writing an email in Outlook Express at the same time that Jabber receives an IM message and MusicMatch is playing an MP3 and ActiveSync kicks off a Money synchronization for our software to blue screen the machine), we must ask ourselves whether it is worth fixing the bug.

This is a pure business decision: say we know from the past that identifying this kind of mysterious bug can take a developer 5 to 10 days to merely track it down, let alone fix it. This takes him/her off other bugs that are more important (read: those that affect more customers, corrupt data, or whatever). It's not that the bug is unfixable, per se, it's that it is not economically viable to even attempt to fix it.

At this point the software moves from "mostly bug-free" to "good enough".

Good enough software is software with compromises. Those compromises might be because of economic reasons as above, or resource constraints (the software has to be ready by 30 February, no fail, but all development resources are tied up in other activities), or badly- defined requirements (the software doesn't quite do what was wanted because the analyst writing the requirements didn't ask the right question).

So in reality good enough software is the best software we can write given all the external constraints (money, time, resources, inadequate information, etc) placed on us. It's certainly not the best software we can write before we clock out to go see our son's ball game or the best software we can write because we don't understand the problem space and can't be bothered to ask.

(See also this viewpoint from The Pragmatic Programmers, Andy Hunt and Dave Thomas.)