We all know the situation – you’re working on a technology project, and while it would be great to do something the “right way”, time and budget constraints force you to take a shortcut, buy a cheaper piece of hardware, or even just leave a somewhat important feature out of your project.
Anytime you do this on a project, you are incurring technical debt. Technical debt is a term that first came into use way back in the early 1990’s when it was coined by Ward Cunningham, but it is a concept that has taken a while to move from theory to application.
The idea is that anytime you make a less-than-perfect choice, or a choice that you know will later need to be corrected, you are taking on a certain dollar amount of technical debt that later will need to be paid back. So for instance, let’s say for a given ASP.NET web application project, you choose to run with SQL Server Express instead of full blown SQL Server Standard because you want to save $5,000. At some point in the future though, you know you are going to have to upgrade to Standard and do the migration of the data to the new server. Therefore, if you were to look at your overall project portfolio as a financial statement, you should see your costs laid out as such:
Assets:
Software Development of Application – $10,000
Liabilities:
Future SQL Server Standard Upgrade – $5,000
Future Data Migration – $500
By carrying forward the technical debt as a liability, your actual asset of the $10,000 invested in your application is reduced to only being worth $4,500, because it’s about $5,500 short of the “real” solution. Additionally, you can also see of course that you have around $5,500 that eventually, you’re going to have to “pay back”.
The kind of debt in this example is obviously intentionally taken on, since it saves money in the short term at the expense of the long term. However, much of the technical debt that exists in business today is not intentional – it comes from poor quality code, or even delaying a solution entirely, and therefore taking on a technical debt related to your business’s lack of efficiency. For instance, if you work with a low-quality vendor on a $1,000,000 project, but after roll-out you find that it’s going to need to be re-written someday because of poor quality or missing features, you may actually have $1,000,000 of technical debt on your plate – which, though unappetizing, is not at all uncommon.
So, take the time to asses the solutions you currently have rolled out at your company, and allocate some dollars to technical debt. You may find that you have a lot more to pay off than you think.
