When I got my second job, at a startup web design agency, I remember being very happy with the raise in my salary. I was ever so pleased, but the smile faded when I realised I couldn’t defer my student loan payments any more. It was the first time I experienced the pain of working off debt.

In situations where a huge amount of debt accumulates, for example the very Student Loan Company that I was paying back, it is not uncommon for the people holding the debt to try to sell it on. To make this work you need investors to want to buy the debt. This trick is one that translates easily into technical debt situations.

When a client, or manager, requests that a job be done quicker, there is every chance that the team will start to accumulate technical debt. It might be skipping some degree of rigour in unit testing, or automated testing. It may be that we postpone some refactoring that would simplify things going forward, in order to have some feature in time for a milestone. Or even just ignoring some minor issues from the static analysis results.

Whatever, who cares, life happens. There’s no point tearing yourself up over what happened in the past, it’s what you do going forward that counts. So after the rush, or more likely after half a dozen of these technical overdraughts, we’ll try to persuade the client, or manager, to let us take some points out of our sprint to pay of the technical debt.

The what?

Did you really think it would be that easy. Even customers who get what has happened, will try to defer. More than likely you’ll still have this burden hanging over your shoulders at final release time. Yeah, leave it to be fixed in the next version.

The thing is, there’s an easy way to get it paid off, and for the customer to actually ask you to do it. You need to create a Technical Investment Vehicle.

Building a Technical Investment Vehicle is a matter of thinking about the potential asset you have in your technical debt backlog. Taking common backlog items, and turning them into a story, that will form a valuable part of the product. So taking a set of common classes and refactoring them into a command pattern, becomes the ability to easily add new functionality, and make it undoable. Who wouldn’t want that? Taking a couple of days out of a sprint for some nerdy refactoring is a much tougher sell.

This is more readily achievable, if your team is in the habit of making all their work driven by customer requirements. So you need to have good user stories, and strive, even at low level, to make what you’re doing important to the customer. Maybe you’ll create personas to make this easier, but having a customer that is used to high quality stories, will make it easier to produce Technical Investment Vehicles.

Thanks for taking time to read. The car featured is certainly a Technical Vehicle. It was very kind of amdtuning.com and cobrasport.com to let us get so close to the action at the Rockingham round of BTCC last year.