Quality needs to be built into the product from the start - by definition it is impossible to bolt it on after the product is created. Quality can't be 'tested in' at the end by the Quality Assurance department. All this will do is create stress and conflict. It creates a culture where only 'priority 1' bugs get fixed before we ship. Scheduling writing code and testing as separate phases typically results in long bug lists, which make the release date hard to predict.
But how do we create a quality culture? People create the process. People applying the process create the product. Build quality in by having people who want to create a quality product, and a process that guarantees quality.
How do we cope with the demands of creating a quality product, and the demands of the business to release a cost effective product? There is no easy answer to this question. But what companies like Toyota who focus on quality have found is that the quickest way to release a product is to focus on quality from the beginning.
If we don't fix bugs till after we've finished all the features it may seem like we are making more progress, but we won't be able to release because of the bugs, and we won't know when we can release because we don't know how long it will take to remove the bugs. Plus it will be downright hard to remove some of the bugs, especially ones that were put in a long time ago.
It is well known that the longer it takes to find a bug, the more expensive it is to fix, because the developer who originally wrote the bug will have forgotten what they were doing, and other code may rely on the buggy code working in the buggy way.
If we fix all the bugs in a feature as we go we will appear to move more slowly, but when all the features are finished we will be able to release.
Be careful about how we define bugs. A naive implementation of a quality culture will define every undesirable behaviour as a bug. This will cause the team to spend so long on the first features, that they won't finish enough useful functionality to release quickly. Instead concentrate on implementing a useful minimum set for each feature, then move on to the next feature. When all the features have the minimum done, then move on to fleshing them out and improving them. In this way we will have something to release, even if it is not the most elegant solution possible. This gives the business the choice to release early and start making money if they want to, or to keep working on an elegant solution.
So why do developers write buggy code?
Our process needs to be designed so that these factors introduce bugs as rarely as possible. Every time a bug is found we should look at what happened. How did that bug slip through coding and automated testing? Why? Then we need to adapt our process.
In traditional factories there would be piles of inventory between the stages of an assembly line. If a defect was found in one, it would be just thrown away and another piece used. Meanwhile whatever process problem caused the defect was still there and still creating defective pieces. What a waste.
Toyota also believes it is the process that created the defect, not the person. It wasn't the fault of the person who didn't tighten the wheel nut enough, it was the fault of the system which allowed the car to move to the next station without a tight wheel nut.
Apply this philosophy to software development to create a quality culture. 'Stop the line' means that fixing bugs is always top priority. All bugs should be fixed before new functionality is created. (Although, as stated before, bugs are slippery to define.)
How can we create a system which doesn't allow bugs to be introduced? Agile has many techniques to reduce the number of bugs that go undetected.
Quality software is created by professionals who care about doing a good job and a process that encourages them to do so.
Toyota's 'stop the line' philosophy can be applied to software to create a process that guarantees quality.
All of the agile practices work together to create a quality culture.