Software bugs aren't inevitable

[Michael Sparks]

Giles Brown wrote:
> Michael Sparks wrote:
>> 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*.
> <snip>
>> As a result I'd say that the subject "Software bugs aren't inevitable"
>> is not true.
> 
> I think you can argue (I would) that any behaviour that is in the
> specification this "isn't right" is not a software bug, but a
> specification error.  

To a user there is no difference. If the software doesn't do what they
wanted it to do/asked for, then to *them* the person who is accepting
the software it's a bug. It doesn't matter to them what caused it - be it a
buffer overflow, a misunderstanding of a language feature or an incorrectly
written formal spec, it's still a bug to them.

I'm actually a big fan of formal specification (specifically VDM), but
that doesn't stop me realising that it's not a cure-all, and it's also not
an excuse - if code doesn't do what it was asked to do, it's bust.

Regards,


MIchael.