Technical Debt – time for payback!

Posted: August 20, 2011 in Patterns & Practises, Project Management

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

Table 1: Technical Debt Metrics
Metric Description Units
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!

About these ads
Comments
  1. Pratik says:

    The technical debt is the most neglected aspect of product development and probably the most dangerous one. It can result into entire product or feature re-write hampering time-to-market and increasing total cost of ownership of the product. Timely and quality code reviews are very important to mitigate the risks associated with the technical debt.

    I strongly recommend to have good code reviews (2 levels – peer and expert), open house technical discussions, small technical quiz to improve competency, tech-talks and many more. The only way to mitigate technical debt is to increase technical competency of the team members working on the product.

  2. Kamal Gupta says:

    The best way to reduce mitigate this to have proper comments with code reviews from the experts in your project. Always mark TODO: in case you know that it has to be sorted out later in the next iteartion.
    Increasing a tech. debt is as harmful for the long life of the project.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s