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. -- [EMAIL PROTECTED], 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. -- http://mail.python.org/mailman/listinfo/python-list
