Agile Overview → Work Items → Defects → Origins of Defects
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:
- A missed implementation–Something that was not done during the implementation. For example, if a unit test isn't written, the related acceptance test can never fail. Or, perhaps the code itself didn't get a useful set of unit tests created for it. Both of these could lead to a situation where a defect is not discovered until later in the development process, making it more difficult to identify the real cause of the defect and therefore, making it more expensive to fix. It is often much more expensive to fix something later than it is to fix something right away. One way to prevent something from not getting done during an implementation is to actually write less code. Less code means fewer lines of code that require testing, fewer unit tests written by your developers, fewer acceptance tests written by your testers, and less risk that you won't find a defect right away.
- A missed design decision–Something that was not understood well enough, soon enough. If your team is not aware of how the design changes over time, or does not consider how edge cases can play into the overall design or how a new requirement may affect everything that has already been built, then there is a greater risk that your team does not factor in these kinds of changes when they occur. For example, if a new requirement is added that was originally viewed as an edge case for a feature that was completed two sprints earlier, it's safe to assume that unit tests and acceptance tests were not written for that specific edge case. It is also safe to assume that unit tests and acceptance tests were not written for how the feature should behave after the work required to add the new requirement has been completed.
- A misunderstood requirement–Something that your customer wants, but is added later. The whole purpose of the design is to provide your customer with something of value. If your team is constantly making enhancements to what you have already designed, it can be an indicator that the things your customer really wants are not being understood soon enough. An enhancement is just a fancy name for a defect that didn't have well-understood requirements.
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.