Defect or Change Request?

You’ve probably participated in debates about whether a particular complaint from a customer qualifies as a defect (the software doesn’t behave according to specification) or a change request (the software does what it’s supposed to but the customer is asking for new functionality). Furthermore, if you’re a developer, you’ve probably had the following thought: As a developer I don’t really care if this is a defect or a change request. I’ll still have to do it, and my work won’t change either way. My analysis, my code modifications, and my testing will all be the same.

Sound familiar? I used to think that too, but then I realized that isn’t quite the way it works. If the issue is categorized as a defect, there will be a lot of pressure to fix it as quickly as possible. Estimates on a change request are padded on the upper side for safety, but estimates on a defect are padded on the lower side for reputation (everyone loves quick fixes). That means the developer will have a tougher time trying to get time to make the change properly, leading to the inevitable “just patch it now and we’ll do it right later” problem.

Now, maybe you think this doesn’t affect you because in your company you always do things right, either first time or, eventually, after the fact. Well, think again. It may not matter if one or two bugs eat into the profit — but remember, your salary comes out whatever commercial agreement has been reached with the client, so if the commercial department struggles, your salary might eventually be impacted. And you like getting your salary.

Multiple reasons can turn a defect into financial impact: Perhaps you sell fixed-price projects, so that bugs are addressed within the existing budget. Maybe your SLA agreement imposes a penalty if there are too many bugs. Or maybe bad quality affects your reputation, losing you customers. You can’t always escape the change vs. defect problem, so here are a few ways to deal with it:

• Prevention: Maintain constant communication with the customer to stop this problem before it even happens. Agree on an authoritative contact to answer developers’ questions, and get your developers to adopt the habit of asking those questions instead of making assumptions.
• Avoidance: Show your customer that, one way or another, the development effort has to be paid for. You can migrate to a Time and Materials pricing scheme and eliminate the debate altogether.
• Provision: If neither of the previous approaches work, adjust your price to factor in a budget for bug resolution. Be careful not to do an “educated guess” — that’s still a guess. Get into the habit of collating statistics so you have a genuine idea of how much you actually spend on bug resolution, and use that information to drive your estimates.

Needless to say, at the end of the process you should also assess how much time and effort your chosen solution took (nothing is free) and how much time and effort you actually saved. This is pragmatism, not perfectionism: If the solution is more expensive than the problem, you might as well learn to live with the problem.