Back in Chapter 8, Tightening Feedback Loops in the Software Development Life Cycle, we discussed how we tighten feedback loops from a variety of sources for us to ascertain two things:

• Are we building the right thing?
• Are we building the thing right?

Bug reports are a form of feedback that we should welcome, as they are the most straightforward problem detection system we could ask for. They cover many facets of our software, from a user requirement not being quite right to a broken API connection, from the user experience not being satisfactory to performance being suboptimal. 

Some teams try to argue that a bug isn't, in fact, a bug. For example, they may say it's a case of the business requirement being wrong. Perhaps the user didn't know what they wanted. This is old-school contract thinking, which gets litigious because of the upfront promises we've made.

Collaborative thinking would lead us to a more service-oriented mindset, where we would want to delight our customer. Therefore, don't get into semantic wars over what a bug is or isn't; remember everyone is right to a certain degree. Embrace it as good feedback and collaborate to fix the problem.

From a lean perspective, bugs result in one of the biggest wastes we have in the software industry because they slow us down in two ways: 

1. The time taken to rework our software due to building the wrong thing.
2. The time taken trying to write code on top of software that was built the wrong way.

When we get a bug report, for us to have a chance of preventing this kind of bug from happening again, we have to understand the reason it occurred in the first place and fix the underlying problem.

To do this, we need to triage the bug and perform some root-cause analysis. The quickest method is the 5-Whys, a more in-depth approach is the Ishikawa diagram (we showed an example 5-Whys in Chapter 8, Tightening Feedback Loops in the Software Development Life Cycle).

When we use root-cause analysis, we might be surprised to determine that there are some common root causes of bugs. These can be roughly categorized as follows:

• Those caused by the way we write code and design our software
• Those caused by our understanding of the problem
• Those caused by the nature of the problem changing

For the first two points, we can put strategies in place that can bring these directly into our control. For the last point, we can mitigate the problem, primarily by being able to respond quickly to the change. We can also put strategies in place that will build in resilience, so for example, if a change is made to a third-party API,  our service won't be impacted or will degrade gracefully.