With all of the recent global financial news being dominated by various debt crisises, this seems like a fitting time to point out that there is another type of debt that is rampant in IT organizations as well.
This type of debt also sneaks up on you if you aren’t keeping an eye on it and it too can have devastating effects. I’m talking about Technical Debt.
Technical Debt is already well known in the Agile circles as way of quantifying the deficit created by cutting corners on code quality or completeness in order to speed business feature delivery. The “Technical Debt” is the difference between doing something good enough for now rather than doing it right.
The debt metaphor is used because it implies that the organization has taken on liabilities that must be “repaid” (i.e. fixed) at some point in the future. The further along in development you move without getting rid of that debt, the more the debt grows. And like monetary debt, there is a nasty compounding effect at work here as well.
My favorite short explanations of the main points of the metaphor are:
- Skipping design is like borrowing money
- Refactoring is like repaying principal
- Slower development due to complexity is like paying interest
Folks like Ward Cunningham, Martin Fowler, and Israel Gat do a much better job of explaining Technical Debt than I do and I highly recommend reading their work.
So what does this have to do with DevOps? I think it’s becoming increasingly clear that DevOps problems can best be approached and quantified using the concepts of Technical debt. I hear people all the time digging themselves into deep holes of DevOps problems with mindset of “lets just get these features out the door first and then we’ll come back and fix our process and automation issues”. They are taking on massive amounts of technical debt and are usually lacking a way to quantify or account for it.
Let’s try the above definitions on for size with one particularly common DevOps problem — missing or poor quality automation:
- Missing or poor quality process automation is like borrowing money
- Implementing and improving process automation is like repaying principal
- Slower pace of innovation and poor execution due to missing or poor quality process automation is like paying interest
It does seem to fit quite well. And the best part? Aside from being a concept that forward thinking developers have already embrace, Technical Debt has also been proven to be a persuasive metaphor at the executive level. Now we just have to port these ideas and vocabulary to the mainstream of the DevOps movement.
The next time you are struggling to convince an executive to fund and support DevOps work, remember to looking into using tried and true Technical Debt arguments.
Below is an except from a recent video interview I did with Israel Gat of the Cutter Consortium. In this segment he goes into what technical debt is and how it can be used to prove the cost of not “doing it right”.
Update: If you are at Agile 2011, go see Israel speak at one of his sessions. It’s worth it. His session on Wednesday, ‘Super-Fresh Code’, promises to be of interest to anyone grapping with DevOps issues.
