Hi Sam!
Jesper Ottosen

Hey Jesper

Thanks for the response and for sharing the link.

The author claims that the cost of defects is a myth, to which I disagree both from a common sense point of view and from my experience.

Consider this hypothetical situation:

A very well organized Agile team has some UX people working with a product owner over a few weeks to create a new feature. They then work with the tech team to create a solution that will actualize the feature. The tech team works away and release the feature to production.

Now consider that they find 2 defects. One defect concerns the initial user journey, where they forgot to add a “invite your friends route” function (missing specification defect). Another where they were displaying the wrong data for the user (implementation defect).

Now let’s look at 2 scenarios of dealing with the defects at different time intervals.

Scenario 1: The team finds the defects 1 day after the feature release

Missing specification defect: The UX team immediately goes to work to add the “invite your friends route” functionality into the workflow. It’s fairly fresh in their mind and the design artifacts they used have not varied too much since the release. They make the changes, and work with the tech team to deliver the changes.

Implementation defect: The tech team immediately fixes the wrong data issue. Again it’s fresh in their minds and it doesn’t take the same developers long to fix the data problem.

Short time to fix= low cost.

Scenario 2: The team finds the defects 6 months after the feature release

Missing specification defect: The UX team has to remember what the whole feature was about, then they have to create new design artifacts since the ones they used have been superseded by 6 months worth of changes. Some of those changes might conflict with the old requirements which requires rethinking. The simple matter of fact here is that it will take the UX team longer to fix this design problem.

Implementation defect: The exact same thing goes for the data issue. The developers have to revisit the functionality, debugging from scratch and getting up to speed, all of which takes time.

Long time to fix = high cost.

Now add the issue of having people leave the company since the defects were found, and the lost opportunity cost from now having consumers “invite their friends” for that viral growth.

The problem is feedback!

The simple truth is this. Bugs and defects are a form of feedback. Feedback needs to be a) detected and b) dealt with. The faster you can detect feedback, and the faster you can deal with it, the higher quality your delivery system is and therefore your product or service.

If the author is saying they are exceptionally good at detecting and dealing with feedback of the defect type, then that’s awesome. That doesn’t make the problem a myth, it just means they don’t have that problem :)

Like what you read? Give Sam Hatoum a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.