Technical Debt – time for payback!

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!

It’s all in the mind of a pig!

Having worked with Agile teams starting back in 2002, my personal experience is that, the mindset of the pigs on the team is a key differentiation between the success or failure of the project.

It does not matter if you have a local co-located Agile team or a global, multicultural, team spread across multiple time-zones Distributed Agile team – it is as simple as the mindset of the members in the team which can be the difference between successful delivery or failure at every step.

The Agile Manifesto values:

Individuals and interactions over processes and tools

I think the authors got this spot-on for the succinctness of the statement & the fact that it is the very first value of the Manifesto!

Individuals & interactions – especially within the Agile team (the Pigs) are the key.

So, what needs to be in the mind of the pig & why does it matter, given that its commitment to the endeavor is bacon?

The Mind of a Pig

For me – if every individual on the Agile team knows his area of contribution & contributes to the best of his ability on that, constitutes the ideal Agile team.

This expectation includes:

• Understanding the role that individual is performing
• Understanding the deliveries for that role
• Understanding the measurement of “done”
• Understanding how this role impacts the other roles & their deliveries

If an individual contributor can come into an Agile team with the above understanding very clear in his mind, it is of immense help & an major contribution in itself.

Sometime, the understanding of the role in the grand scheme of things can be rather humbling, other times tad disconcerting – but all-in-all extremely vital mindset for the success of the project.

One might argue, that having individuals with this mindset, is an asset to any project & is not dependent on the execution methodology used & indeed will be a success in Agile & non-agile project.

But like I started – it’s all in the mind of a Pig!