Every decision made during the course of a project can affect the quality of the final product. Compromises in functionality, design, or implementation invariably come with a cost, which must be paid. Without an adequate measure of the debt a product is carrying, no strategy to repay it can be formulated, and the project may ultimately become bankrupt, affecting your business case, your users’ productivity, and your organization’s bottom line. Taking from the concept of technical debt, Jordan Setters gives it a quality twist. “Quality debt” is the cost in time and money paid by the system's users through productivity lost due to inefficient functionality. Learn how to measure, track, and prioritize this debt. Discover ways to manage your quality debt and how to organize development to pay back the interest and principal as soon as possible. Take back an approach for using quality debt as a tool to inform project stakeholders of both the costs and the added business value of their decisions and choices.

1.
BT7
Session
6/6/2013 2:15 PM
"Quality Debt:
Is Your Project Going Bankrupt?"
Presented by:
Jordan Setters
PlanIT Software Testing LTD, New Zealand
Brought to you by:
340 Corporate Way, Suite 300, Orange Park, FL 32073
888‐268‐8770 ∙ 904‐278‐0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com

2. Jordan Setters
Planit Software Testing, Ltd.
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.

3. Quality Debt
Is your project going bankrupt?
Presented by:
Jordan Setters
jsetters@planittesting.co.nz
So . . . What is “Quality
Debt”

4. A Brief on “Technical Debt”
Ward Cunningham:
inventor of Wiki, and all
around brainy guy
Shipping first time code is like going
into debt. A little debt speeds
debt
development so long as it is paid back
promptly with a rewrite. . . . The
danger occurs when the debt is not
repaid. Every minute spent on notquite-right code counts as interest on
that debt. Entire engineering
organisation can be brought to a
stand-still under the debt load of an
unconsolidated implementation,
object-oriented or otherwise.
-Ward Cunningham, 1992-
A Brief on “Technical Debt”
Debt can be simply broken into two parts:
Principal:
The direct cost of fixing those structural
flaws in the production system – at a
minimum is a cost calculated by:
• number of hours to fix
x
• fully burdened hourly cost of those
involved – design, developing, testing

5. A Brief on “Technical Debt”
Interest:
Continuing costs:
Contin ing costs The amount of time
amo nt
(therefore money) developers spend in
working around known design flaws,
limitations, and bugs while coding new
features – i.e. inefficiency
See also: Business Risk, Liability, Risk, &
Opportunity Cost
© Planit Test Management Solutions Pty Ltd 2008
A “Quality Debt” Concept
“Technical Debt” often doesn’t present
itself into defects during the testing or
use of the system - It is a debt to the
developers
We (testers) deal with decisions that
affect the quality of the system to the
user - This is debt to the user /
business . . . ”Quality Debt”

6. A “Quality Debt” Concept
Jordan Setters:
Stylish Bass god, and the
best tester in the world
(according to him anyway)
The first time code is released to
production is like going into debt. A little
debt speeds the project along, so long as
it is paid back promptly with a rewrite. . . .
The danger occurs when the debt is not
repaid. Every minute the users spend on
not-quite-right functionality counts as
interest on that debt. Entire development
projects can be brought to a stand still
stand-still
under the debt load of bad functionality,
defects or otherwise.
-Jordan Setters, 2012: shamelessly paraphrasing Ward
Cunningham -
What it looks like when we get it
wrong
© Planit Test Management Solutions Pty Ltd 2008

7. Types of Quality Debt
Unintentional:
These are not strategic, b t are a result of
Th
t t t i but
lt f
people doing a bad job and is often
occurred unknowingly:
•
•
•
Bad Coding*
A poor design approach
Incomplete requirements*
requirements
Types of Quality Debt
Intentional:
Project makes a conscious decision to
optimise for the present at the expense of
the future. Characterised by decisions
that include statements like:
•
“If we don’t get this release done on time, there
won t
won’t be a next one
one”
•
“We don’t have the time to . . .”
•
“We can work around by . . .”
•
“We’ll clean this up later”
•
“We’ll do that after go live . . . in another phase”

8. Be sure you are taking on the right
kind of Debt
Some debt is taken on in large
chunks:
“We don’t have time to do it right, so we’ll fix
it after go-live” – akin to large debt like buying
a car, it can be tracked and measured.
Be sure you are taking on the right
kind of Debt
Other debt accumulates from taking
hundreds of short cuts – akin to Credit
short-cuts
Card debt
•
•
•
Easy to incur unintentionally
It adds up faster than you think
It’s much harder to manage and track
© Planit Test Management Solutions Pty Ltd 2008

9. Debt MUST BE SERVICED
There is a tipping point
• D th by a thousand WTF’s
Death b
th
d WTF’
• The debt of the hundred little inefficiencies
building up, adding time and frustration to
their daily tasks
• This is “Interest” on your debt.
Often not paid by th project, b t paid by
Oft
t
id b the
j t but
id b
the business in lost time and
productivity.
Debt MUST BE SERVICED
When do you know you have Problem
•
•
•
•
•
•
•
A growing dislike for the system admitted by
developers, testers, and users
Small defects never get fixed
A bad user experience or UI is a clue it is
rotten to the core
Growing number of workarounds
Consistently not meeting requirements
Lack of knowledge of what the system does
and why
Unused features

10. Debt MUST BE SERVICED
When are you in over your head
•
•
•
•
•
•
•
Deep contempt for the system
All knowledgeable developers, testers,
and SME have disavowed the system
or left
Infrequent software releases
Bug fixes take too long
Lots of “Sorry”, “OMG”, “WTF”, and
Sorry
OMG
WTF
“$%#&*!!” comments
Documentation is no longer useful as a
test oracle
Work arounds are now enshrined in
the user experience
GMAS
Example
© Planit Test Management Solutions Pty Ltd 2008

11. Managing Debt in an Agile World
The way debt can be measured and dealt
with in Agile
Hardening Iteration
Debt a part of product backlog
More opportunity to payback debt before
it becomes an issue
More likelihood of accumulating ‘credit
card’ debt
© Planit Test Management Solutions Pty Ltd 2008
The “No Defect” Mindset
“What he needs is some way to pay back.
Not some way to borrow more ”
more.
- Will Rogers
At any given time, the highest priority is to
eliminate bugs before writing any new code.
© Planit Test Management Solutions Pty Ltd 2008

12. How Do You Measure Quality Debt
Maintain a “Debt List” with defects
Keep a track of the “Debt Backlog”
p
g
•
when debt is paid off, remove it from the
list;
•
if a debt starts becoming “old” then increase
the priority of that fix
Must have a useful measure to safeguard
against the accumulation of “credit card” debt
How Do You Measure Quality Debt
You can calculate a cost for Quality Debt
(((0.1 ∑ LSV) + (0.25 ∑ MSV) + (0.5 ∑ HSV)) x Time(h) x $ /hour)
LSV = Low severity defect
MSV = Medium severity defect
HSV = High severity defect
CAST surveyed 745 applications and the
resulting analysis d
li
l i determined the
i d h
average Technical Debt = $3.61 per line
of code.
© Planit Test Management Solutions Pty Ltd 2008

13. Communicating Quality Debt
“For every (dollar) of competitive
advantage gained by cutting quality it
quality,
costs $4 to restore it; and software is an
organisational asset and decisions to cut
quality must be made by executive
management and reflected in the financial
statements.
statements ”
- Ken Schwaber
http://www.infog.com/presentations/agile-quality-canary-coalmine
© Planit Test Management Solutions Pty Ltd 2008
Communicating Quality Debt
This is a concept that
y
immediately resonates
with executives and
project management
Presents well to both
non-technical and
technical stake holders
alike
lik

14. Communicating Quality Debt
•
•
•
Should be contextualised
Discuss in terms of money and time rather
time,
than features or functionality
If you can calculate the time of workarounds,
then compare with project business case
Compare “good debt” with “bad debt”
© Planit Test Management Solutions Pty Ltd 2008
Communicating Quality Debt
Treat the discussion as an on-going
dialogue rather than a single presentation;
it may take several discussions before the
nuances of the metaphor fully sink in.
© Planit Test Management Solutions Pty Ltd 2008

15. References
Curtis, Bill. Paying Down the Interest on Your Applications: A Guide
to Measuring and Managing Technical Debt. New York: CAST,
2012
McConnel, Steve. Technical Debt. www.ontechnicaldebt.com, 2007
Schwaber, Ken. www.infog.com/presentations/agile-quality-canarycoalmine
Strutz, Nathan. Holistic Program Quality and Technical Debt
(presentation). CF. Objective, 2011
Szynkarski, Alexandra. 3 Concepts to Aid Developers in Addressing
Techinical Debt. www.ontechnicaldebt.com, 2012
Appendix A: Debt Glossary
Technical Debt: These are the activities that a team or team
members take shortcuts on now that will impede future
development if l t as i
d
l
t let
is
Quality (Testing) Debt: There is a diminishing ability to verify
the functional and technical quality of software: the Break/Fix
mentality
Configuration Management Debt: Integration and release
management become more risky, complex, and error-prone
Design Debt: The cost of adding features is increasing toward
the point where it is more than the cost of writing from scratch
Platform Experience Debt: The availability and alignment of
people to business objectives that involve software changes is
becoming more limited or cost-prohibitive
Non Debt: Feature backlog, deferred features, cut features, etc.
Not all incomplete work is debt
© Planit Test Management Solutions Pty Ltd 2008