Dealing with Defects

Simplicity is a beautiful quality for code to have but its very difficult to avoid complexity entirely.

Because of this software has had, and always will have defects. As an engineer you don't need to beat yourself up about this, you have a difficult job and occasionally mistakes will be made.

So given that even if were striving for perfection we won't achieve it we need to know how to deal with defects when they inevitably are uncovered.

When Is A Defect Not A Defect

Preceding a defect being unearthed there will usually be someone heard to say "Its not supposed to do that", but we shouldn't always assume that every time unplanned or undesired behaviour is observed that this is the result of a defect.

The surfacing of technical debt will very often look like a defect but its important to recognise when this isn't simply a mistake but part of the design of the system.

These situations need to be given special importance, quite often but not always defects are static in nature in the sense that there impact on the code base and the user doesn't change.

Technical debt is dynamic in nature, it generally gets worse over time both for the user and the engineer.

This dynamism will usually also apply to the solution, once you start to feel the affect of technical debt it must be nipped in the bud, it isn't just a mistake its in-built in your code.

Not All Defects Are Equal

Defects will be uncovered in a random order, you won't necessarily find the worst ones first and there isn't always a correlation with the impact of a defect and the amount of time its going to take to fix.

All this means you need a triaging process, the chances are you aren't going to have the time to ship defect free so you need to make sure your making the best use of your time and concentrating on what will most affect the user.

What annoys the user and what annoys the engineer are not always the same, the engineer might be very annoyed by a slight glitch in the UI because he or she knows it it could be better, the user may be blissfully unaware of this potential enhancement.

Once you've accepted your not going to be able to fix everything you need to resist the urge to jump on a defect as soon as its discovered and instead document it and regularly review and asses which will have the biggest impact on the user.

The user will probably put up with or be unaware that the button isn't quite rendering properly, what they won't forgive is nothing happening when they press it.

Attacking with the Toolbox

Because on the whole defects are caused by people making honest mistakes they will very often fall into the similar categories. This similarity can help us first of all detect them but also formulate a plan of attack to fix them.

Before any effort can be made to fix a defect our energies should first be concentrated on finding the correct way to reproduce it.

A defect that can't be reproduced is difficult to repair and even harder to verify as fixed.

Once you've been burnt by the defect fixing process a few times learn to trust the intuition it will nurture, trust that voice in your heard that says "I bet this is because..." and recognise the patterns that certain defects produce in code.

First and foremost we want to fix the defect so we can ship but we also need to give some though to ensuring that we don't have to spend anytime fixing it again in the future. Always give some though to how this could be prevented from happening in the future and share this knowledge with everyone in the team.

Its pointless to try and pretend that you can get to a level where your code won't have defects, no-one is perfect and mistakes will always be made, what you can strive for is developing a strategy for dealing with defect to ensure that there impact is minimal both on you and your users.