Technical Debt - Part 1 - Stop accumulating debt

Much of the material I found when searching for "technical debt" has been related to trade-offs a developer will make favoring features or timelines over a superior (or modern) technical solution. The initial definition for technical debt is most often attributed to Ward Cunningham in a 1992 piece about the WyCash portfolio management system. Ward states:

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.

This seems accurate for software development, but I think we need to expand the definition to include technical operations as well. Many of the technology choices of a software product may seem fully rational at the inception of a project, but over time may turn into technical debt. As an example, a product initially developed for the Solaris operating system in the late 1990's was probably cutting edge, but that same product running in our data centers today is far outside our competencies to support when the majority of our systems are now linux based. It is pretty clear to me that technology choices turns into debt over time if they are not periodically refreshed and upgraded.

Technical debt is a big liability that my team carries. The larger the debt, the larger the burden we carry to support that debt. We've taken several opportunities to outline the liabilities and risks of leaving the debt unpaid, discussing upgrades to older technologies and suggesting application changes. In many cases business owners will listen to our pitch and then politely tell us that they accept the risk and the debt. The problem with this response is that it doesn't relieve the pressure and frustration on the technical operations team because when the debt comes due, we'll still get the call and the scrutiny.

We need to balance the budget. Just as in finance, you can't get out of debt by continuing to spend more than your income. The first step in tackling our technical debt is to ensure that new applications are being developed on technologies that carry no new debt value. We will establish the list of technologies and versions that are completely in our wheel-house. An item on our list means we have experience with the technology and have created best practices including scaling, monitoring, and configuration. We will evangelize this list to our development teams and lead with our recommendations for all future development work. We'll need to stay current with this list to show our commitment to balancing our technical budget.

If there are occasions where an engineering team needs to use something we don't have on our list, we need to have a discussion about the requirements. All to often we're presented with a technology that has been chosen because it's new, is all the rage, or suggested in some off-hand comment by an executive. We will be open-minded about new technologies, and likely we'll need to build capability prompted by a request to use something not on our list. As long as we have discussed the requirements, this is a healthy process and will further shape our supported technology list over time.