Design – Build – Run: Applied Practices and Principles for Production-Ready Software Development

2.2. Why Quality (and Scope) Matter

Studies have shown that the cost of fixing bugs later in the lifecycle is generally higher than finding and fixing them earlier on. In the previous chapter, you saw that projects can fail or be seen to be a failure because of poor quality and poor scope.

I'm a firm believer that no system is completely defect-free and the short story I mentioned at the start of this chapter would go some way to support this statement. That's not to say that your processes shouldn't strive to achieve zero defects; it simply means that you're probably not going to achieve a truly perfect solution. In any case, you'd first need to define exactly what a "perfect solution" means. It will almost certainly mean different things to different people. If you can stand back and say, "It's my best work yet," then you're probably in a good place. That doesn't mean to say that you couldn't identify some areas of improvement or refinement. The problem is that you don't always get the time to revisit your work in the way that you would like. You test and review during the project to ensure that as many defects are captured and fixed as possible, although there's always the opportunity for some defects to slip through the net. In fact, software is very often shipped along with a set of "known issues." These known issues have been identified and are not seen as show-stoppers for the release. Minor defects are often carried over into future releases. The defects may affect a small ...