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?

 

JS: As stated before, debt is not necessarily a bad thing, as long as it is the right kind of debt, and as long as it is taken on strategically and with a payment plan. So it is not about avoiding all debt. But having a means by which to measure the debt, even a budget of how much debt the project is willing to take on and afflict upon it's end users. And this strikes at the heart of the debt metaphor. Everyone knows this from their own lives. We know that sometimes you have to take on some debt, in fact, it is nearly impossible to live life without some debt. It is when you let that debt start running rampant, and you get in "over your head" that the debt stops facilitating your life of happiness and starts keeping you awake at night.

 

NW: I read a quote from Ken Schwaber where he said that "decisions to cut quality must be made by executive management and reflected in the financial statements." What are some situations where a decision to cut quality is the right move to make, and is do you agree with Schwaber's statement that it should be left only to executive management to make that call?

 

JS: I think it is something (at least in the context that I am talking about) that needs to be handled on a case by case basis. It depends on the structure of the business, the project, the delegated authority or responsibility, and the size of the quality cut and the risks involved. Ken Schwaber's statement was intended to communicate that reducing the quality of your product is as an important a decision as any financial decision made by the company. Just like a company wouldn't leave it to a tester to decide to take out a million dollar loan, so too the tester shouldn't be left with decisions that could cost the company the same amount in software debt.

 

 

A test consultant for Planit Software Testing, Ltd. in New Zealand, Jordan Setters has been in software testing for twelve years in both the public and commercial sectors. Jordan has worked with companies as diverse as Telecom NZ, testing their capacity to lawfully intercept communications for law enforcement agencies; Transpower NZ, helping implement a new electricity market system to manage New Zealand’s national power grid; and the Ministry of Social Development. Jordan is proud of his hands on approach to testing. A proponent of pragmatic testing approaches, Jordan is passionate about achieving the best possible system for the users, using whatever means and methods necessary.