In a meeting today, I brought up that some applications were taking on technical debt. Some of the people on the call weren’t familiar, and we ended up discussing it at length.
This term was first coined by Ward Cunningham, and is explained quite well by the venerable Martin Fowler, HERE.
Now, if you google technical debt, you will see that tons of people have written plenty on this topic. However, I wanted to just cover a few specific points.
Technical debt is the notion of deferring “cost”, in exchange for a faster, albeit less-than-ideal alternative. For example, you’re writing an application, and instead of creating a data layer, you just put inline SQL everywhere in the application, because it’s faster. Because of this trade-off decision, this application will cost more to maintain in the future, in exchange for a lower cost now.
I think most people “get” this idea, but why then is it so prevalent? Actually, let me say it the opposite way, why is proper code so ridiculously rare to find? The reason is because it’s difficult to quantify the financial cost of this technical debt. In the business world, everything comes down to the financial aspect – the ultimate cost for what they are getting right now.
It seems to me there are several quantifiable ways that technical debt can be translated into a dollar amount. If poor decisions were made during development, that sped up the time-to-market, but impacted:
- Performance – then this technical debt converts into lost productivity of the users and perhaps downtime.
- Security – then this technical debt converts into breaches, lawsuits, brand damage, and physical loss.
- Application stability – then this technical debt converts into lost productivity, lost data, helpdesk calls, down time for users, etc.
- Maintainability and Supportability – then this technical debt converts almost exponentially into maintenance costs. Each version will cost more to work on, testing will take longer, and adapting changes for the business will become more and more difficult. This almost inevitably results in the application collapsing under it’s own weight. It eventually becomes cheaper to buy a replacement or re-write the app, than it would be to continue on.
Hey, what do you know – those align perfectly with programming best-practices – must be a coincidence! 🙂
Applications that rot:
However aside from this, there is another facet of technical debt that isn’t talked about as much – that is applications that don’t stay current. I refer to these as “Write-n-Rot” applications because they just sit and rot. From the business perspective, there is no compelling reason to make any changes because the app does what it needs to. However, the hardware, the OS, the application run-time continue to grow, evolve, and change. Next thing you know, you have an application that is going to be super-expensive to update, because it hasn’t kept up with the changes.
Maintaining your car:
This type of technical debt is akin to not maintaining your car. You can go year after year and never change the oil. After all, look at all the money you’re saving every 3 months! Until, your engine seizes or something catastrophic happens. See, you didn’t “save” money over that time, you simply deferred the cost. Not only did you defer it, but the cost later is always so, so much more than the maintenance would’ve cost.
Instead of paying $19.95 every 3 months = ~$80/year – when the engine goes after 3 years, that costs $2,000+ to replace versus the $240 that the oil changes would’ve cost during the same time period.
Maintaining your house:
Another common metaphor for this is not maintaining your house over the years. It may seem like you are saving or avoiding these costs. In reality though, those relatively small costs of painting and fixing small problems, turn into enormous problems that costs 10’s of thousands of dollars to fix – or you could instead take 10’s of thousands of dollars off your asking price. Again, you didn’t actually ‘save’ any money by avoiding maintenance, you only deferred the cost – and the deferred cost can be an order-of-magnitude more than the incremental maintenance would’ve been.
So what do we do?
So how does one bridge this gap then? The business cares about the application doing what it needs to, they don’t care about technical debt, because it doesn’t appear to be a tangible risk, to them.
I think the answer to educate the business. This is nothing more than modern version of the quality triangle, where you can “pick two”:
Except now the “good” side really represents two things “good, it won’t be cheap, but you’re not taking on technical debt” or “good, will be cheap, and instead of money now, you are taking on technical debt”.
In other words this simplistic notion of “look at all the money I’m saving by not changing the oil in my car!” is naïve and ignorant. Businesses can’t keep going forward with blinders on, making decisions based off the short-term cost.
Technical debt is a very real part of the trade-off that businesses make, when they choose “cheap” over “right”. We have to start changing this mindset, this erodes the agility and capabilities of so many companies, it’s just a bad business model to follow.