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. This obviously puts the focus on specification errors, but standard development processes don't guarantee the absence of specification errors either. Btw, I'm not arguing that this type of approach is widely applicable, but the "you'll always face specification errors" argument isn't well reasoned I think. Cheers, Giles -- http://mail.python.org/mailman/listinfo/python-list
