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: Lotus, Notes, NZ, Technical Debt

 Print | Posted on Monday, March 14, 2011 7:40 PM | Filed Under [ Notes/Domino Web Development Miscellaneous ]