Often as developers we are stuck evaluating only the negative artifacts of technical debt. However, what if we looked at the debt metaphor from the point-of-view of our business executives. Would we reach the same conclusions?
In this presentation, I demonstrate that technical debt is not always something to be avoided. In fact, when debt is incurred responsibly, it can become a powerful tool that improves the communication between stakeholders and technologists.
As we inspect this concept, I offer rules and guidelines for evaluating when debt is good and when it is toxic. Once we have a firm understanding of this framework, I present strategies for prudently measuring, paying, and using debt. At the end of the presentation, both developers and business stakeholders will gain a new vocabulary for describing project decisions that will maximize the collaboration between both teams.
2. #craftingdigital
Who Is This Guy?
Steve P. Green
Steve currently serves as the Chief Executive
Officer for Blue Rivet, a collaborative digital agency
in Kansas City.
My professional experience
I consider code an art form, and have worked to master
the craft over the last 15 years at some of the finest
technology companies in Kansas City.
3. #craftingdigital
Understanding My Bias
Seth Godin
One of the most-loved marketing gurus on
the internet, generating 50 million views per
month.
I believe that building software is fun. More importantly, I
view it as something worthy of mastery.
“If it’s work, we try to do
less. If it’s art, we try to
do more.” – Seth Godin
5. #craftingdigital
A Quick History Lesson
Ward Cunningham
In 1992 at a developer conference, he was the
first to use the “Technical Debt” metaphor as a
way to explain software decisions.
“Shipping first time code is like going into
debt.
A little debt speeds development, so
long as it is paid back promptly with a
re-write.
Every minute spent on not-quite-right
code counts as interest on that debt.”
– Ward Cunningham, 1992
6. #craftingdigital
Towards a Definition
Bad Code is Often Invisible
Bad code is dangerous because it is often
invisible to the business. However,
expressing it as debt helps expose the
problem.
Stuff that is wrong with the
application, even though it will
pass functional requirements.
Technical debt is often like a Band-Aid. It will hold the
application together to get it through testing. However, it
is rarely a long term solution and eventually needs to be
replaced.
7. #craftingdigital
Consequences of Ignoring Debt
The code will become
uncontrollable
Developers will become
overly specialized
1
2
3 The solution will become
inflexible
Staff will become
demoralized and
unmotivated
4
Given that the software “works”, it can
be tempting to ignore the debt.
However, this can have fatal
consequences.
By actively engaging in debt
conversations, the business can ensure
technology is aligned with the overall
corporate strategy.
Why Should the
Business Care?
8. #craftingdigital
Consider This Kitchen
Technical debt builds quietly over time
until it becomes unmanageable
No one sets out to design software poorly; rather it happens slowly over time. Consider this
messy kitchen. The designer didn’t set out to create this disaster. Instead, it happened naturally
over time as the result of small bad decisions that incrementally destroyed this space.
9. #craftingdigital
An Example in Code
This is a massive SQL query
from the Daily WTF called the
“Query of Despair”.
However, even though it is
hard for us humans to
understand, the computer has
no problem.
The “Query of Despair”
11. #craftingdigital
Common Indications of Debt
A developer’s primary
responsibility is to solve “how”.
If they don’t know “how”,
they’ll try to work through it
instead of looking for help.
In order to combat this, we
have to look for common
indicators that problems exist.
This allows us to begin
identifying debt.
Coders Hate Asking
for Help
Velocity: large decrease in the
number of tasks completed per sprint
1
Stress: development team is routinely
stressed during deployments
3
Production: on-going issues keep
coming up even after fixes
4
Quality: number of bugs per
release increase rapidly
2
12. #craftingdigital
Start Training Your Spidey Sense Look for common “smells” that indicate possible problems.
“Don’t worry about the documentation for now.”
“The only one who can change this code is Bob.”
“ToDo/FixMe: this should be fixed before the prod roll”
“Does anyone know where we store the database password?”
“I know if I touch that code everything else breaks.”
“Let’s just use our QA time to finish that feature.”
“The client doesn’t care, just get it done!”
13. #craftingdigital
Finding Debt In Existing Codebases
Automated Toolsets
Robust development such as Visual
Studio provide toolsets to evaluate code
metrics.
Use Code Metrics
When evaluating existing projects, the following code
metrics can become key indicators that debt exists.
Cyclomatic Complexity
Measures the number of logical branches in the code.
The higher this number, the greater chance of debt.
Code Coupling
Measures the inter-connectedness of components
within the solution. The more connected, the higher
probability of debt.
Test Coverage
The amount of code exercised by automated tests. The
lower the coverage, the higher likelihood of debt.
Code Commits
Frequent code commits to the same area of an
application can be a sign of technical debt in that area.
14. #craftingdigital
When is Debt Most Likely to Occur?
SCOPE
TIME
Planned
Velocity
Actual
Velocity
Business
Pressure
Planned Release Full Quality Release
Technical
Debt
Understanding when debt commonly occurs makes it easier to track.
15. #craftingdigital
Debt Happens Naturally
Software Rusts
Like most technology, software can become
old and rusty.
Once software is released to production it can be easy to
forget that it may be incurring debt naturally. As
vendors update their toolsets, it is highly possible that
we will gain unintentional debt.
Applications that
reference legacy or
antiquated libraries are
probably debt.
16. #craftingdigital
The causes of technical debt can be categorized into four distinct types.How to Categorize Debt
Reckless Prudent
DeliberateInadvertent
“We don’t have
time for design.”
“What’s the
single
responsibility
principle?”
“We’re just going
to have to launch
and make a plan.”
“Next time I’ll use
a new responsive
design.”
17. #craftingdigital
Always Avoid Reckless Debt
Reckless and Inadvertent Reckless and Deliberate
Real-World Examples
These real-world examples make it easier to understand how reckless debt can
occur.
19. #craftingdigital
Why Should The Business Manage Debt?
The business is not motivated by…
The business is only motivated by outcomes, not technical details. If a piece of debt has a negative impact, discuss that
with the business in non-technical, monetary terms.
“The Code
Is Crufty”
20. #craftingdigital
How To Talk About Debt
In order to fully engage with the business,
we must always express technical debt in
monetary terms.
A good strategy is to use the application’s
maintenance budget as a gauge for the
impact of technical debt.
Talk About Debt In Terms of
Money
This often requires the development team to immediately estimate the time to resolve
debt as it is incurred.
21. #craftingdigital
How To Payoff Debt
It’s a Business Decision
No matter how much we wish it wasn’t, remember
that the decision to substantially refactor is always a
business decision.
There Are 3 Options:
There are three different strategies that you can employ
when evaluating how to pay down your debt.
Debt Repayment – refactor the entire “not-
quite-right code” into something better.
Debt Conversion – replace the problem code
with a “good, but not perfect” solution.
Interest Only – choose to live with the costs of
the debt.
1
2
3
22. #craftingdigital
Consider This Example
Most of us would probably say “it depends”. Is it
raining? How far do you have to go?
There are a bunch of variables that would
determine if the solution, though not ideal, is
adequate.
Is This a Good Solution?
23. #craftingdigital
Consider This Example
What would a debt repayment look
like? Well, the best solution given
our limited space might be to simply
unpack the box and load the smaller
contents into the car individually.
Debt Repayment
24. #craftingdigital
Consider This Example
What might debt conversion
look like? We could try to make
the current situation a little
better by providing padding on
the arm rest and securing the
box with the sunroof.
Debt Conversion
25. #craftingdigital
Consider This Example
What would an interest only
solution look like? Well, we
would just choose to deal with
the current situation without
making any changes. We just
deal with the fact it’s not the best
solution.
Interest Only
26. #craftingdigital
Segregate Debt User Stories
Use a separate debt backlog
Creating a backlog for debt items that is
separate from features provides an easy way to
catalog your technical debt.
Use a Kanban Board
A Kanban or task board can be a great way to visualize and
track the technical debt you build during an iteration.
Centralized place for developers to
log debt
Provides a clean separation between
debt and features
Makes the debt accumulation
completely transparent and visible
Provides helpful insights when
compared to the feature backlog
27. #craftingdigital
Don’t Ignore the Debt
You’re Still a Professional
If you’re not active in managing your debt, your
solution will begin to look like this.
Actively look for ways to pay debt
Ignoring the debt will eventually create a huge mess.
Instead, provide developers easy ways to pay down
debt.
Allocate a Buffer Task
This is a shared task or user story provided for
each iteration where developers can log their
effort for small refactorings or improvements.
Use Clean-up Releases
A purely technical release can be used to cleanse
the codebase. These are most helpful
immediately following an aggressive or hectic
development period.
28. #craftingdigital
Enforce a Definition of Done
What does “done” really mean?
“Done” can mean different things across all project
constituents. Is it “code complete”? Has it been
tested? Has it been reviewed? What about UAT?
What is a “definition of done”?
A definition of done is a list of tasks distributed to the
entire team that clearly states when something is
“done”. It should include:
Completeness
Unit Tests
Code Review
Integration Tests
Documented
Approved
29. #craftingdigital
Build a Healthy Debt Culture
The Most Important Question: “Why”
Remember that the goal of the code review is to
learn and teach. We want to encourage
intentional coding.
Always in person with the whole team, usually at the
end of the sprint.
Only review the commits in that sprint, but everyone
comes prepared to discuss.
Author start with something their “proud” of and
something their “ashamed” of.
Avoid the mundane items that can be caught by
static code analysis or tests.
Encourage an atmosphere that celebrates code.
Mob Code Reviews: It’s Not About Quality
Code reviews are the most under utilized tool an architect
can use to foster team building and learning.
30. #craftingdigital
Refactoring Your Debt
Refactoring is a natural part of the
development process and should be
encouraged.
Refactoring Is Not a Dirty
Word
1 Current Context:
Are you currently
working with the
code?
2 Comprehension:
Can you easily
understand or
change the code?
3 Test Coverage: Do
you have sufficient
test coverage to
support the change?
31. #craftingdigital
Great Coders Love to Refactor
Watch Out for This Guy
While refactoring is natural, we must be
aware that some coders just want to re-
write everything.
Understanding that building software is like
writing a book shows us that technical debt is a
natural part of the process.
Developers are often self editing to remove
small amount of debt, even if they are doing it
without realizing it.
Refactoring is an
expected part of
coding.
32. #craftingdigital
Refactoring Goals
Improve the Overall Design
Improve Readability
Reveal Or Isolate Defects
Improve Efficiency and Organization
Why Should You Refactor?
When refactoring, it is important to keep these primary
objectives in mind:
Refactoring Should Be Incremental
To prevent refactoring from becoming
dangerous, it should always be systematic and
incremental.
Pain Driven Development
34. #craftingdigital
Maximize Signal-To-Noise Ratio
What is “Signal”?
Signal is anything in your code that has meaning
or value. If it doesn’t provide value, then it’s just
noise.
Use the TED Rule
Signal is any logic that follows the TED rule.
Terse: code should not be overly wordy.
Expressive: it should be clear what the code is
trying to do.
Do One Thing: code should have a clear
responsibility, and it should do it well.
35. #craftingdigital
Identifying Noise
Noise is in competition with signal.
Below are some examples of common noise patterns in code.
Huge Classes
Long Methods
Repetition
No Whitespaces
High Cyclomatic Complexity
Excessive indentation
Overly Verbose
Names Matter
Name selection has a huge impact on
readability. Remember, it’s about
conveying intent.
37. #craftingdigital
Refactoring Techniques
Composing Methods: The refactoring techniques in this group streamline methods, remove
code duplication, and pave the way for future improvements.
Moving Features: These refactoring techniques focus on safely moving functionality between
classes, create new classes, and hide implementation details from public access.
Organizing Data: These refactoring techniques help with data handling, replacing primitives
with rich class functionality. Another important result is untangling of class associations, which
makes classes more portable and reusable.
Simplify Conditionals: Conditionals tend to get more and more complicated in their logic over
time, and there are yet more techniques to combat this as well.
Simplify Method Calls: These techniques make method calls simpler and easier to understand.
This, in turn, simplifies the interfaces for interaction between classes.
Dealing with Generalization: Abstraction has its own group of refactoring techniques, primarily
associated with moving functionality along the class inheritance hierarchy, creating new classes
and interfaces, and replacing inheritance with delegation and vice versa.
See: https://sourcemaking.com/refactoring
38. #craftingdigital
Be Part of the Solution
“Always leave the code you’re
editing a little better than you
found it.” – Bob Martin
The Boy Scout Rule
When teams accept the responsibility for the design, the system as a whole improves over time.
As the software evolves, developers take an active approach to enhancing the system. Much like
picking up trash on the side of the road, if everyone does just a little bit, the highway remains
clean for everyone.
41. #craftingdigital
What’s Up?
Huh?
Technical Debt is Good…
Technical Debt is a phrase frequently
used to describe negative artifacts that
occur during the completion of a
development cycle.
Debt is: Bad Stuff in Our Code
Technical Debt is a metaphor used to
explain what happens during a project
that non-technologists can easily
understand.
It is Also: A Way to Communicate
The technical debt concept is really two related, but separate ideas.
42. #craftingdigital
The Power of a Metaphor
Finding Common Ground
It is often easier to explain complex ideas using
analogies, especially when communicating across
professional disciplines.
Perspective Matters
Technologists and business stakeholders have
fundamentally different perspectives. Using a common
metaphor can improve communication between them.
Technology thinks in terms of black/white
Technologists view the world in binary. Things are
either right or wrong, red or green, on or off, 0 or 1. It
either works or it doesn’t.
Business operates in infinite shades of gray
Stakeholders view the world as a series of options.
Delivery can be a varied mix of perfect and
adequate solutions.
43. #craftingdigital
Using Debt As a Tool
Remember, It’s About Value
Accruing responsible debt is perfectly
acceptable as long as your getting adequate
business value
When can debt be good?
When actively managed, introducing strategic technical
debt into a project can become a powerful tool to achieve
business objectives.
Decrease time to market
Introducing debt can shorten the amount of time it
takes to release a solution.
Maximize operating capital
Strategically accruing debt can allow the business to
prioritize tasks according to value.
Delay development expenses
It is sometimes necessary to defer high development
costs until a later date.
44. #craftingdigital
Employ Strategic Design
All parts of a system can’t have the
same high level of quality.
Therefore, the team can actively
decide which parts of the system
can accept lower quality.
Do all parts of a system
have the same quality?
46. #craftingdigital
Perfection Is the Enemy of Innovation
What is Innovation?
Innovation is one of the most over used words
in our industry. For me, innovation is the ability
to use technology in unexpected ways.
Stop Perfecting, Start Innovating
In order to innovate, you have to be willing to make
mistakes. If you spend too much time perfecting, you are
likely missing more important opportunities.
What the business thinks is innovative seems
simple to a technologist.
Furthermore, what is innovative to a
technologist is often meaningless to the
business.
47. #craftingdigital
Prove You’re a Good Coder
The Power of Perfection
A king once asked a painter, “prove you’re a good artist”. After
contemplating, he stood quietly over a piece of paper and
drew a perfect circle.
What Is the Most Innovative Thing You’ve Built?
In a job interview, I was once asked what was the most
impressive thing I’ve ever made. I love data structures,
so I answered: a non-recursive red-black tree.
49. #craftingdigital
Session Takeaways
The technical debt metaphor is a
powerful tool that can close
communication gaps. The ensures
that both technology and the
business are fully engaged in the
discussion.
Debt Is a Tool
The simple truth is that no one
is perfect. Technical debt is
going to happen, it’s
unavoidable. However, if
we’re smart about how we use
this knowledge, we can make it
work for us.
No One Is Perfect
The solution isn’t just the
responsibility of the technical
staff, but also the business.
Allowing them to engage during
the full lifecycle ensures joint
ownership of project decisions.
It’s Everyone’s
Responsibility
50. #craftingdigital
Next Steps
Remember that a little
knowledge can be dangerous.
To be a great developer, I highly
recommend these resources to
guide you towards deeper
understanding.
“If it’s work, we try
to do less. If it’s
art we try to do
more.”
– Seth Godin
51. BE BOLD +
DO GREAT WORK
steve.green@bluerivet.com
@stevepgreenkc
/stevepgreen