Editorial Note: I originally wrote this post for the Infragistics blog. Head over to their site and check out the original. While you’re there, have a look at the other blog authors and their product offering.
If you’re not already familiar with the concept of technical debt, it’s worth becoming familiar with it. I say this not only because it is a common industry term, but because it is an important concept.
Coined by Ward Cunningham, the term introduces the idea that taking shortcuts in your software today not only means paying the price eventually — it means paying that price with interest. In other words, introducing that global variable today and saving half a day’s work ahead of shipping means that you’re going to pay for it with more than half a day’s labor down the line.
The Power of the Metaphor
I’ve spent significant time doing IT management consulting in recent years, after spending years and years writing code. And I can tell you that this metaphor for shortcuts in the codebase is a powerful one when it comes to communication between the business and the software development group. When you explain software decisions to managers and MBAs using the language of economics, they get it.
Because of the metaphor’s power and subsequent effectiveness for business concerns, it is often used to describe the health of projects, particularly vis a vis deadlines and milestones. The developers may communicate that an aggressive deadline will result in technical debt, making features in the future take longer to ship. Analysts and project managers might account for technical debt when discussing slipped deadlines. IT upper management might ask for an assessment of the amount of technical in an application when making a strategic, replace/retire/rewrite decision.
The problem of technical debt is for most people, in essence, a problem of time to market.
But I’d like to talk today about the human side of the problem. And, make no mistake — in business, all human problems are also business problems,viewed with a wide enough lens. Unhappy humans are unhappy workers, and unhappy workers are less productive. Yet, this angle of technical debt is seldom discussed, in my experience.