If we really want to achieve software with an extremely low defect rate, it is not enough to react to software bugs and fix them after they have been introduced. One of the main principles of my style of software development is that we have to go on the offensive and eliminate or reduce the possibility of their creation.
Now this sounds like a good principle, but it is one of the hardest to achieve. It is hard to achieve because it fights the human desire to get quick results even if the results are not completely correct. We want to show something that works in most cases, but bugs often occur in the least used cases. Also if we tried to avoid every kind of potential bug out there we would probably never finish our task. So we want to find all the situations where avoiding an issue is more cost effective than dealing with the bugs that are caused by them. If you have ever spent a week, day or even an hour on a bug, you will realize how much extra code you could write to avoid the issue and still come out ahead.
Basically go through the kind of bugs that occur and ask yourself “How can I reduce creating this kind of bug again? Is it cost effective to do so?” After a while you will realize that additional code will often get you to a low defect rate sooner.