Twenty years ago, Ward Cunningham coined the term technical debt to refer to immature software code. Ward referred to code that was unconsolidated, or written in chunks without doing the necessary work to integrate the chunks into a cohesive body, reflecting the current understanding of the underlying business problem and requirements.
“Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation…”
Over the last two decades, the software development community has come to appreciate the dangers of accumulating technical debt. Much of the Agile movement is predicated on the value of incremental release and re-factoring, which allows a body of code to mature as it is developed, and test-driven development, which places a value on continuous regression testing of every change, in order to avoid introducing defects into working code. But pressure to introduce new features and new products remains. Many organizations have accumulated a tremendous amount of technical debt in their in-house developed software, as well as the premises-hosted ERP, financial, and CRM software that they licensed and then customized. As a result, they are behind in applying critical updates, because they can’t reverse-engineer their own code quickly enough to determine how to apply it to the new code base supplied by their vendors. As Ward predicted, they have been “brought to a stand-still.”
For many organizations, migrating from their current debt-laden application code base is part of the value proposition of a move to software as a service (SaaS). They get to “write off” their accumulated technical debt and avoid taking on new debt, by letting the SaaS vendor handle all maintenance and upgrades. Of course, it’s rarely that simple; moving from a troubled legacy application usually results in a troubled deployment of whatever replaces it. But when considering the business case for SaaS, it’s important to look at the level of technical debt accumulated in the current application. At least some of the value of a successful migration will come from retiring that debt, and freeing up scarce technical resources for other investments.