Software bugs aren't inevitable

[Michael Sparks]

Paddy wrote:

> A work colleague circulated this interesting article about reducing
> software bugs by orders of magnitude:

The problem that these sorts of approaches don't address is the simple
fact that simple creating a formal spec and implementing it, even if
you manage to create a way of automating the test suite from the spec
*doesn't guarantee that it will do the right thing*.

The hidden assumption is that the formal spec will be correct. If it
isn't then you have the same problems as before. Sure you might be able
to reduce the number of bugs, but you can be certain of one thing,
given:
   * Customer has a need
   * Customer communicates this to Supplier
   * Supplier translates needs to spec
   * Supplier translates spec back to english
   * Customer agrees spec

This involves human communication, and misunderstandings happen all
the time then.  Sure it can be easier to detect errors at this stage,
but you can't guarantee that it will do so. You can almost guarantee
though that people will misunderstand each other from time to time.
A purely engineering approach to dealing with correctness cannot
guarantee that misunderstandings won't occur. Those misunderstandings
translate into bugs, no matter what approach you use.

It's why I find XP and agile approaches interesting, they're often more
than just engineering.

As a result I'd say that the subject "Software bugs aren't inevitable"
is not true.

Regards,


Michael.
-- 
Michael.Sparks at rd.bbc.co.uk, http://kamaelia.sourceforge.net/
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP

This message (and any attachments) may contain personal views
which are not the views of the BBC unless specifically stated.