You are here

You are here

Defect differently: 4 defect management game-changers

public://pictures/rouan.png
Rouan Wilsenach Software Developer, TES Global
 

You'll find a lot of advice on the Internet on how to organize the flow of defects your team has to deal with—which bug tracker to use, how to divide responsibilities, which statuses to track.

But even with the clearest defect management cycle in place, you may still be stuck wasting a lot of time on defects that never really go away. Here are some ways of thinking differently about defects that will help you get on top of things and stop that annoying flow of issues.

Defects aren't bad

It's very easy, and natural, to think of defects as bad things, because they make us feel as if we've done something wrong. We call them "bugs," and talk about developers creating them or "introducing bugs."

In 1947, Grace Hopper's colleagues at Harvard found an actual bug—a moth—inside their computer. I suspect that its presence in the computer was, like so many bugs we deal with today, a surprise. Not a mistake, but an example of the real world interacting with the computer in a way they didn't anticipate.

What most of us do when we hear about a bug is to say to ourselves, "This is bad. I should fix it." When we do this, all we end up achieving is fixing one defect. We fail to learn something new about the system and the way it interacts with the real world, so a similar defect could appear again. What should have been eliminated as a known defect arises again.

Hopper's team treated their bug as a curiosity, and they taped it to their log book. You should adopt the same attitude and say, "Oh, that's interesting. I didn't expect that." Then you can approach the defect with curiosity and see what it teaches you about the program, the infrastructure, the users, and even your team.

Do a root-cause analysis

Getting a bug fixed is great; making sure you prevent similar bugs is even better. For every defect you investigate, ask yourself the "Five Whys" so you can start to understand why the defect really occurred.

On the surface, a bug might seem as if it were caused by a simple programming error, but when you start asking questions, you may find that it happened because the code changed many times at the last minute. This may have been due to a misunderstanding about the business requirements.

Maybe the cause of this was two team members who were struggling to talk to each other. This could be because they're both new to working remotely. You wouldn't have thought so at first, but after digging deeper, you may find that doing more training on remote-first conflict resolution can stop these kinds of bugs from happening.

Make sure to track your bugs so you can learn about your system over time and see which kinds of issues happen most often. When a particular area of the product is causing many issues, remember to ask the big questions. Should you redesign this? Do you have too much technical debt? Or even: Do you need this feature at all; is it financially worth the upkeep?

Another trick is to keep track of the manual steps your team has for fixing issues that crop up often, so you can automate the solutions instead.

Make succeeding the default

Defects give you feedback about your software development process as much as anything else. How easy is it for things to go wrong? What if it was easier for things to go right?

If you start making changes whenever a defect occurs, you can make it harder to make mistakes the next time around. We call this creating a pit of success. The idea is that you make it easier to slide into success, rather than having an environment where mistakes are hard to avoid.

The change you make could be as simple as adding a little more logging, or as drastic as deleting a whole feature. When you fix a defect, write a test case so you can automatically prevent a regression. Rethink the software's design to ensure it makes doing the right thing frictionless.

Talk about common anti-patterns and mistakes. What about publishing a post-mortem for your team (and other teams) to read after a major issue is resolved? Then more people can understand the causes, next steps, and potential pitfalls.

For example, you may learn that your database behaves in a way you didn’t expect. Telling the rest of your organization will be a huge help so they don't fall into the same trap.

Be open about your defects

When we think of defects as bad things, we end up feeling embarrassed when they happen. Though natural, this response leads us down a complicated path where it's more difficult to deal with the real issues.

Don't be scared of your customers; they appreciate openness. So tell them when you have a defect and explain how it affects them. Not acknowledging a problem doesn't make it go away. They'll be affected whether you talk to them about it or not.

When you talk to your customers about defects, you not only help them understand what’s going on; you also give yourself an opportunity to show your willingness and ability to sort things out for them. Publish your outages and degraded services as notices on a public status page. There are commercial products dedicated to providing these and you can find many examples online (including the ones from GitHub, Twitter, and Tes).

Share your successes too. Write blog posts about how you dealt with an outage or fixed a gnarly bug. This will appeal to potential employees because they can get a glimpse into how you work.

Look at the big picture

Every piece of software will have defects, and many teams struggle with how to deal with the real causes of these defects. Defect management shouldn't just be about defining a process for dealing with individual defects, because focusing on each instance in isolation causes you to miss the big picture.

By thinking about defects differently, you can learn more about your customers and eliminate entire classes of defects.

Keep learning

Read more articles about: App Dev & TestingTesting