I make software less bad for a living, so I'm intimately familiar with the fact that software is buggy. One reason for that is simply that modern software is pretty complex and getting every last detail right is, it turns out, quite tricky. None the less, we do have ways to make software at least a lot less buggy than a lot of what gets shipped, so a reasonable user of software might demand to know why we don't.
In fact, we do – but it takes time, and the developers who ship their buggy software early get told about their bugs by users and get whatever other benefits (commonly involving money) flow from having their software in use, whereas the competing developers who decline to release their product until it's bug-free are not gaining such benefits, and have to find all the bugs for themselves. Onf of the benefits gained by the team that releases something buggy today is that they get feed-back from their users on which features it would be useful to add, where the team who doesn't release until it's bug-free may be spending a lot of time and effort on implementing a feature that users will, once it gets released, turn out to never use.
This is why the software industry is very fond of the concept of
a minimal viable product
– one that does enough, and does it well
enough, that folk to whom it's available shall find it useful, enjoyable or
otherwise worth having, despite its limitations and faults. Those folk then, in
the course of using it, if they can be induced to give feed-back to the
software's developers, discover what improvements matter most to their use of
it, which enables the developers of the software to make their product better
sooner than a competitor who waits until they have something perfect
to
ship.
That's not, of course, universl – when it comes to designing the safety systems for nuclear reactors or aircraft, the importance of getting it right is sufficient to motivate not putting the software into use until there is strong confidence that it is right. Such systems typically have a well-defined set of requirements, to which those who'll be using it won't add once they start using it. This makes it possible to specify exactly what's wanted and then, though this will be expensive, to make sure the software does meet those requirements. The folk who do such work have to be a lot more careful than those of us for whom shipping buggy software today is better than shipping less buggy software in the future. Indeed, the one I know typically supplies the customer with a proof of correctness of the code delivered, and a promise to give all the money back and fix the bug if they ever find one.
So bug-free software does exist, but it's expensive and only possible where
it's possible to specify exactly, in advance, what it's meant to do. If you
can't do that, what does bug-free
even mean ? At some point in the
history of word-processors, spell-checking wasn't a usual feature, so users
wouldn't have considered the lack of it a bug; but now that it's a standard
feature of typical word-processors, the lack of this feature in a word-processor
would be considered a bug by most users. The developers might classify the bug
report as a feature request but, if they fail to address it with the same
urgency as a severe bug, they'll lose their users to competitors who do provide
that feature.
Many programs now save their state on a regular basis, in a way that lets them resume where they were on a restart, whether after the user exiting the application, a crash – whether of the software itself or of the operating system it's running on – or, indeed, a power-failure that caused the computer to shut down unexpectedly. This significantly reduces the annoyance and inconvenience to the user of crashes in such software, making them mere inconveniences – far more easilly endured that the lack of features added recently, that wouldn't be available to the user if the developers had declined to ship the software because they knew it sometimes crashes.
Once users are familiar with a program that does a job for them, however buggily, any competing program will, by the simple fact of being unfamiliar, be less convenient for them to use, even if it is less buggy (or, indeed, bug-free, to the extent that that's a meaningful concept). The one-off cost of getting used to the less buggy newcomer may suffice to keep them using the buggier program they're used to. Furthermore, if the buggier program is widely used and is implicated in interactions with others – for example, if users commonly exchange files saved by it, in a format peculiar to it – the less buggy software must, at the very least, be able to interoperate with it; failure to do so would be a bug, indeed, since the user in practice needs it to support their interaction with the other users of the buggy program.
Thus the buggy software, that ships early instead of delaying release until all the bugs are found and fixed, gets established among users, gets the feedback its developers need in order to prioritise the improvements they could make and thus deliver more value to users sooner, and gets to define users' expectations of software in its category. All of this places those who ship early, with known bugs, at an advantage over those who try to fix all their bugs before they ship anything.
So software is buggy, and that's better than not having it available to use.
Written by Eddy.