The US economic outlook is looking bleak & the markets are going flip-flop everyday since the S&P credit-rating downgrade – all of this in response to the US Nation Debt of over $14 trillion & counting!
Do you know, as developers, what is the Technical Debt in your code-base?
Have you been able to estimate, measure, track & payback this debt before it becomes a burden & you too face a credit-rating downgrade by your customers?
Surely, the popular Project Management tools like – TFS, Jira, MS Project etc., should be able to tell you these metrics?
No? Think again
What is Technical Debt
This article will not focus on the definition of Technical Debt, there are tons of well-written articles out there with more details than I can ever hope to cover. Some of the most useful links I have referred to while writing this article are:
Technical Debt – a basic primer from Wikipedia
Technical Debt – the different kinds of debts & more depth in understanding
Technical Debt Quadrant – by Martin Fowler, prepares the kind of mindset needed to address this topic
Paying down your Technical Debt – by Jeff Atwood, a good article to understand why paying down is so important
Is Technical Debt still a useful metaphor? – interesting read. I think the term is even more relevant today than before, but this article has an interestingly different view point.
With the education out of way, my focus for this article is to put forth some practical steps & techniques I have used in my previous projects to pay down Technical Debt.
Robert McIlree has proposed a method to measure Technical Debt. But like the author mentions – some of the parts are based on approximations & we need a more solid method to estimate & project the costs.
Raj Anantharaman mentions another technique using TFS for the measurement & graphical representations.
The technique I am putting forth below is a mix of both Robert & Raj’s work – but generalized to work with any Agile or non-Agile process you might be using & independent of any tools.
To bell the cat
Let us consider a project (Agile/non-Agile does not matter) which has a list of business requirements.
This list can be called a Product Backlog (Agile) or a Business Requirements Document (non-Agile). For simplicity of explanation, let us use the common terminology of Product Backlog to mean both the Agile & non-Agile description of this list.
Along with the Product Backlog, create another list called the Technical Debt Backlog – which, at the start of the project, might be a list of the Technical Debt inherited to the team like: existing services or code-base being used as part of the project, existing schema’s etc. If you are lucky enough to start from scratch, this Backlog will be empty.
Now, for every Sprint/Release/Iteration, record all the items which are termed as Technical Debt as line items in the Technical Debt Backlog.
Estimate & prioritize the Technical Debt Backlog the same way as you would any of your Product Backlog items & you are on your way to Technical Debt freedom!
For the Mathematically-minded
Here are some interesting metrics which can be generated from the Technical Debt Backlog
|Debt per release||The measure of Technical Debt items introduced into the code-base per release||number|
|Debt per resource||The measure of Technical Debt items introduced into the code-base per resource||number|
|Debt Reduction Velocity||The measure of Technical Debt items closed/released per release||number|
|Debt Aging||The measure of how long the Technical Debt item was sitting in the Technical Debt Backlog before it was taken up in a release||Days|
|Debt Cost||The measure of how much the debt costs||Man days|
These calculations are simple & straight way of looking at the Technical Debt in your project by listing out the items explicitly, estimating & prioritizing them & having your team work on these items.
Technical Debt – like all debt items – can be a very powerful tool to meet your short-term deliveries.
Similarly like all debt items, the longer you have Technical Debt in your code-base, the more interest it gains & the more expensive it is to payback what you owe.
Beware & take care!