Technical Debt is related to some of the expedient design and code
choices -- that result in more work later.
Technical debt is a metaphor to describe the extra costs that are
incurred based on the expedient design/code choices.
The debt metaphor was first used by Ward Cunningham in 1992.
The main topics of discussion in this workshop were:
- Education and Selling technical debt
- Meaningful technical debt metrics
- Agile development and technical debt
- Refactoring and velocity
- Testing
- Risk
One of the biggest conclusions of this workshop was the
answer to this question:
- What is the "currency" of technical debt?
- The answer is "Time"
(note that it is not quality or dollars)
This was a surpising insight -- because most of the discussions of technical debt are focused on "quality". But
it is useful to remember that when you are taking on technical debt, you are trying to "save time" -- and you have to pay
back technical debt later, and the technical debt is paid in "time".
You make design/coding choices that save you some time now
and cost some time later.
We also formulated three important questions about technical
debt.
- What is borrowed?
- What is our payback strategy?
- Interest rate - how much time will be needed later?
(In other words, when we find ourselves in a technical debt
situation -- either from an intentional strategic implementation
choice
or from design/coding gaps that we discover later --
we need to understand how much time we have saved in the
present,
what is the likely timeframe for scheduling reengineering
and refactoring work, and how much more work will be required
later.
It doesn't need to be a formal analysis, but it helps
to keep track of the debt.)
Educating and Selling the idea of technical debt
Different stakeholders are motivated by different values, so you
won't necessarily give the same explanation of technical
debt
to each audience.
- Executives: motivated by financials
- Middle managers: motivated by delivery and risk
- Technical staff: motivated by
- an interest in developing their own skill set
-
building quality products, using their creativity
- having fun
in their work
Executives and middle managers do not need to have a detailed understanding of technical debt -- but they do need to
have enough knowledge to understand what they need to do.
- For example, they need to understand why choosing to take on some technical debt early in the project will allow them
to have an initial product sooner, but it will increase the amount of work to be done in the second release (and therefore
it will probably require either more staff or a longer schedule).
In explaining technical debt, two facets are important
- Technical debt costs are about "understanding the system"
- When you have bad spaghetti code, you have some technical debt.
- It may not need to be fixed immediately, but it won't be understandable forever.
- Readability and Code Quality are generally indicators of low technical debt
- Change
Technical debt is often good.
- Many people are ready to label a system with high technical debt as "poor quality", but it isn't true.
- We choose to "invest" -- it is a "technical mortgage" that we plan to pay off over time
- On the other hand, some projects are out of control -- they treat technical debt as if each developer has technical debt
credit card that they can use at any time
- This leads to chaos
Meaningful metrics
The time/schedule curve is the most direct measurement of technical debt
- but unfortunately, time/schedule is a trailing indicator -- it gives you information about the debt when it is too late
to do something about it
There are other metrics to consider, such as "code quality"
- code quality is good because it is a leading indicator -- you can use code quality data to predict the amount of refactoring
that may be needed later
- but today's code quality metrics are difficult to correlate with defect rates, bug fix intervals, and so on
We can use some of the standard "automated metrics" for code quality:
- cyclomatic complexity (McCabe metric)
- test coverage
There are a couple of interesting "non-automated metrics" to consider:
- define a "readability metric" (for example, if you do regular code
inspections, get the inspectors to
assign a readability grade to
each code module)
- use the "developer joy" metric -- a self-assessment by each developer of how happy the developer is about the code they
are checking in
Agile development and technical debt
- Common code ownership reduces technical debt
- makes code more readable, developers get more rapid feedback
- everything is more transparent
- Pair programming helps readabaility
- Agile development doesn't automatically reduce technical debt
- in fact, if you have poorly written unit tests, you might even have higher technical debt because of the need to refactor
unit test code after each coding change
- But agile development will help you identify technical debt
sooner
Agile velocity and refactoring
Should refactoring work count as part of the count of Story Points
in an agile project?
- for big refactorings, maybe
- for small daily continuous refactoring work, no
For managing the product backlog in the context of regular refactoring, you might consider using the Four Color Backlog
model from Philippe Kruchten.
In this model, the product backlog items are in four categories:
- green: traditional customer features
- red: bug fixes
- yellow: infrastructure and architecture stories
- black: refactoring and technical debt
If you have a product backlog with refactoring items in it, then
the technical debt is the set of refactorings that
are deferred
or delayed.
This is a useful way to think of technical debt. If you have accounted for the essential refactoring work as "black"
items in your product backlog, the accumulated technical debt is the sum of all of the refactoring items in the backlog.
You need to have a plan to keep this technical debt from growing too large and expensive.
In other words, technical debt is "deferred refactoring."
Testing and technical debt
The most common technical debt issues surrounding test:
- missing failure scenarios
- inadequate code-level support for running functional tests (you may need more test hooks to make it easier to run test
scenarios)
Risk and technical debt
This is a good research area. We want to know:
- What are some good ways to quantify technical debt?
- How should we try to influence decision makers?
