Where does technical debt come from

Over the past year I’ve been dealing with some technical debt across a couple of different ASP.NET applications that we recently inherited. As part of that work I’ve spent a bit of time thinking about technical debt, how to deal with it, and how to avoid it. Describing the subject of technical debt as interesting might be overstating things a little however it is a subject which is relevant to most developers at some point in their career.

So when I read this article (Lotus Notes - a Double Edged Sword) it struck me as a great example of where technical debt can come from. The post describes an application which was thrown together quickly to help co-ordinate disaster relief volunteers working to help with the recent earthquake in Christchurch New Zealand. Here’s a snippet from the post:

The speed of development and ease of deployment (zero installation, fault tolerance, and client independent) was just one side of the sword. The other side of the sword is the speed at which you can develop & deploy doesn't leave time to consider the user interface or experience and the default isn't particularly inspiring (not that coordinating arrival times and accommodation is EVER going to be sexy)!

I’m not picking on Lotus Notes here as you can easily find examples of this sort of this occurring with any development environment, however Notes’ capabilities as a rapid application development platform do make it a prime example of how temporary or quick fix applications can end up being used for a much longer time period than intended. In fact back when I was developing Notes and Domino applications I remember many times where a client looked at the quick and nasty sample prototype I’d thrown together and said “It looks great, let’s put it live!”.

Examining this in the context of a disaster scenario is interesting as the priorities are shifted – speed is king. Often when it comes to technical debt you can place the emphasis on the developer to insist on doing things properly in the first place and to refuse to compromise on quality in order to save time (as much as possible), and that doesn’t fly in a time of crisis. Instead, in my opinion the emphasis needs to shift to the business to ensure they recognise the technical debt and budget some time to go back and either retire these temporary applications, or spend some time bringing them in line with good development practice.

Identifying that rapid development can sometimes come with consequences is a great step towards avoiding large amounts of technical debt later on down the track – of course the other steps involve taking time out to address those issues before they become a larger problem.

Tags: , , ,

Posted on Monday, March 14, 2011 7:40 PM | Notes/Domino Web Development Miscellaneous

Like this? Share it!

  • # re: Where does technical debt come from
    Gravatar
    Commented on 3/15/2011 12:22 AM

    I've been thinking about the root cause of technical debt as well. We have a lot of it in business applications. Traditionally, the explanation for the debt is incompetence or time, most often it is time.

    Yet, then I noticed that in my own pet project (JungleDragon) I was acquiring technical debt as well. Strange, since there is no real time constraint and I am the only one working on it. The perfect environment to do things right. Yet the problem is still there, albeit somewhat smaller. Why?

    Eventually I concluded that in my opinion, the root cause of most technical debt is a desire for meaningful progress. Customers demand this, but also developers themselves think like this. At the end of a day, they want to say that they build feature X or screen Y. They don't want to say that they streamlined the interfacing, refactored a dirty class, or improved the documentation. You want something to show for your time invested.

  • # re: Where does technical debt come from
    Gravatar
    Commented on 3/15/2011 3:29 PM

    What's also true is that I think some people "think better" in code. You can spend time planning and drawing architecture diagrams all you want, but sometimes the game all changes when you start coding something and realise you need to change your approach

    With that attitude it's easy to write some quick code to make progress (as you say) and then forget to go back and tidy it up once you've proven your approach is viable.

    I think in your example you could probably label what you experienced as the price of progress, rather than the true evil of technical debt :) Everything I've read about your Jungle Dragon experiences sounded like any change of direction was more of a valuable lesson learned than true technical debt, but obviously you're a lot closer to it than me.

    Definitely agree with you regarding refactoring / improved documentation - but that's where a good team lead / dev manager earns their money, by realising the need for that time to be spent and arguing the case to the business.. in an ideal world anyway :)

Post a comment
Please add 8 and 1 and type the answer here:
Remember me?
Ensure the word in this box says 'orange':