Origins of Defects

A defect is a bug, an issue, or some problem with the a product. A defect can be identified by a customer, by a member of your sales or support organization, and (most often) by a member of your own team (a tester or an engineer, for example).

A defect can be many things. No matter how you define them, they are often caused by one of the following:

It is worth it to take the time to explore the edge cases and to fully understand what you intend to build before you build it. By making sure that your team understands the requirements better, you are reducing an opportunity to miss a design decision, which in turn reduces the odds that something will be missed during the implementation. All of this will lead to better code, fewer defects, and greater customer value.

One way to view all of this is to view defects in the same way as financial debt. When one is in financial debt, it requires extra energy to get out of. Among the factors included are interest payments, loan payments, and fees. In much the same way, having a large backlog of defects requires you to have meetings about that backlog, discussions about each defect, time for your team to research the causes and solutions for each defect, and so on. Among the factors included are coding debt, design debt, and requirements debt. Fixing a defect requires that you set something else aside. In the same way that financial debt can affect an individual's lifestyle, so can defect debt affect the way that your team can make progress. If your team is spending too much time on defects, you have that much less time to spend improving your product, adding features, and so on. The goal is to eliminate defects. The reality is that some number of defects will always be there, but the goal should be to reduce them to zero.