Original Post Date: Friday, September 9, 2011

I have recently being following an animated thread on LinkedIn “Death of a Metaphor – Technical Debt.” It’s been live for 2 months with over 200 contributions from dozens of different people.  The discussion was launched by questioning whether continued use of this metaphor makes sense.  The discussion thread weaves and bobs around actually answering this question but it’s amazing how passionate the world is on this topic.  My personal opinion is that it’s a perfectly adequate metaphor because it helps create a discussion between IT and the business leaders in terms that both can understand – dollars and cents. 

Sometimes during software development decisions are made to forgo structural quality to meet some other objective – additional functional requirements, time to market, etc.  How many of us have been involved in a development project where it was more important to get the product out the door than it was to get it done right – we take short cuts with the intent to go back and do it right once the immediate fire drill is over.  The problem is that once the product is out the door and meeting the customers expectation - how do we convince the business that there is as much (maybe more) long term value in fixing a product that is seemingly working than in investing in new features that will make the product more appealing to more users.  What business leaders may not understand is the cost of continuing to maintain and grow a structurally questionable - sometimes brittle – application.  Technical debt is the monetization of that cost making it possible for IT to communicate the value to the business of creating and maintaining a structurally sound application.  Check out this blog for a good discussion of technical debt and how to prevent accruing it.  “Technical Debt gets the Message Across”.