Investigating Higher Quality Software
blrice.net
blrice.net
I really disagree with this. Asides from the fact that tests can't prove the absence of bugs, it's very easy to write a test suite that avoids the unhandled edge-cases; most people do without thinking about it. Your test suite is the tool you have created to search for bugs and should be written in that adversarial mindset rather than as a certification that you actually did your job.
Is this really true? Judging by their decisions, most people's Holy Grail is more like something reasonably good and shipped on time. 100% bug-free code is already possible, but few are willing to pay for it.
University ideals, versus the real world.
I mean, supposedly NASA paid $1,000 per line of code and still got 0.11 defects per 1,000 lines. By that metric, windows would cost $40 billion to develop, but it would still have 4,400 defects in it.
Write explicit code, write tests, have QA staff and procedures, build what the stakeholders what.
I guess the biggest problem with software quality is not that we don't know how to do it, but that it's expensive.
Flinging crap out fast is sometimes seen as a valid business model (unfortunately): that crap is only expensive to you if you have to maintain it, but that's not your problem if all you're trying to do is to "exit".
On the other end of the spectrum (like where I work at now for example), we take a lot of effort and time to make sure our code is not crap - but that is an expensive decision both in terms of money and time.