Re: [Hampshire] Software bugs & impending liability

Top Page

Reply to this message
Author: Stephen Rowles
Date:  
To: Hampshire LUG Discussion List
Subject: Re: [Hampshire] Software bugs & impending liability
Stephen Davies wrote:
> I'm wondering how other LUG Members would tackle the release of software
> with known bugs and would it stop you from developing software in the
> future if you had the spectre of being sued for bugss in your software.
> Remember that the Microsoft EULA makes them NOT Liable for any defect in
> their Software although how that would ever standup to the scrutiny of a
> court I'm not sure. Perhaps this is why they are on the same side as the
> Linux Foundation.
>
> Stephen D
>

It is inevitable that a complex piece of software will have bugs,
anything beyond the most trivial piece of software is impossible to
produce completely bug free. Obviously as a developer I try to minimise
the bugs in code I write, and I would like to think that there are not
too many. But even when the code is technically flawless (it does happen
sometimes) there can still be bugs which have come from a
misunderstanding of the requirements, or bugs that have crept in due to
the requirement changing half way through. You can have done all the
defensive programming, ensure buffers are checked, user input sanitised,
all memory allocated freed etc. etc. but you can still end up with
something that doesn't quite meet the requirement in some obscure side
case that was badly documented in the original requirement. You can also
have issues with code that doesn't work well when interacting with other
code due to both sides interpreting the interface spec. slightly
differently.

These kinds of errors will always happen on projects where the
requirements are written in English and not some formal specification
language. Most use cases are very simplistic diagrams with a few
paragraphs of text, you don't stand any hope of producing a bug free
implementation given that sort of input ;). And for most projects they
idea of formal specification is complete overkill (unless you are trying
to control a nuclear reactor, armed UAV etc.).

I would argue that 100% correct code is almost impossible in very large
systems, and also not required. 99% of code written and used in the
daily life of a computer doesn't need to be mission critical. In most
cases we are not talking about software that will cost peoples lives if
it goes wrong, we are talking about things that will be a minor
inconvenience. Is it really the end of the world, for example, if the
buttons don't quite line up on a tool bar? It would be classed as a bug
but would you really stop the shipment of a piece of software over it?

Given that nature of most software it would be economically infeasible
to ensure that all code is either 100% bug free, or that all bugs in the
code are documented prior to release, nobody would every release any
software or the cost of that software would be so astronomical that
nobody would buy it.