With a better understanding of quality debt, software development companies can avoid bankruptcy that many organizations have faced over the years. In this interview, test consultant Jordan Setters helps teams understand the difference between helpful and harmful debt.
Choosing Quality Debt: An Interview with Jordan Setters
Noel Wurst: I guess just to get started, we should try to pinpoint what exactly qualifies as "quality debt" and how does it differ from "technical debt?"
Jordan Setters: The key distinction I would make between "quality Debt" and "technical Debt" is that where technical debt usually focuses on the cost and impact on development and future development cycles (and there are many sub-categories of technical debt,) quality debt focuses on the impact of implementation and quality decisions on the end user and business; how those decisions affect their ability to do their day to day job. Does it impose a workaround on them? Does it mean that they cannot achieve the productivity gains that they were wanting from the system? Development teams can sometimes get so isolated and removed from their user base (particularly in traditional development methodologies) that they either fail to take into account the impact on the actual user of the system, or they rationalize and minimize that impact to better suit their development goals.
NW: I've read where you've attributed some of the causes of quality debt's accumulation to compromises being made in "functionality, design, and implementation." I'm curious as to what leads to those compromises even being made if we know the negative outcomes that arise from making them? In other words, if developers know the results of their negative or counter-productive actions, why do they continue to make them?
JS: Compromises are usually made so that the project can meet it's timeline goals. In the original words of Ward Cunningham: "...a little debt speeds the development along". And we all know this. If we don't make compromises in functionality or the quality of the delivered functionality, few software projects would ever go live. So debt is not a negative thing, actually it can be an extremely positive and useful thing, as long as it is the right KIND of debt, and as long as it is measured, tracked and paid back. The problem comes where we defer functionality or defect fixes (go into debt,) but then never actually follow up implementing them (pay the debt back). Then what was supposed to be a short-term deferment turns into long term problem for the user.
NW: The title of your presentation, "Quality Debt: Is Your Project Going Bankrupt," gives a pretty intense wakeup call to developers, in that you're asking them "is your project going bankrupt" and not "how to keep your project from going bankrupt." For those who attend your session and discover "yes, my project is going downhill fast," what are some things they can do to reverse that slide, before it's too late?
JS: Yes, I chose that title because it is more emotive. Going bankrupt is a very stressful and emotive thing for anyone. But the first step in dealing with the problem of a project on a terminal trajectory is to realize that this is what is happening. The next step is quantifying and communicating it to the people with the clout to make the hard decisions. It has always been a problem for testers to get their voice heard, and too often we are criticized for being "pessimistic" or "negative" by other development team members; while the tester sees themselves as the lone voice of sanity in a sea crazies. This debt metaphor gives another means, or voice to communicate the situation to project or business owners.
NW: And for those who've just begun a development project, or are soon about to do so, what measures can be taken to prevent, or at least reduces the accumulation of this debt?