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 protfolio mangement 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.
We’re actively compiling our list now and I’ll share that once we’ve pulled it together. In future posts, I’ll write more on “Technical Debt” and the plans I have about identifying and reducing our debt.
Mental Effort 
I went to a talk on this, framed as application security debt. http://www.appsecusa.org/p/debt.ppt http://vimeo.com/32909119
It’s an interesting part of the technical world, and one that surely underlies our deepest dreams to “burn the ships”.
LikeLike
This is similar to a typical product lifecycle management problem in hardware design – the engineers use all sorts of non-standard parts that seem elegant in the design phase but wreak havoc on supply chain costs.
For technical debt data – I ran into an article in InfoQ recently about a report on technical debt costs from CAST. It looks very data rich:
http://www.castsoftware.com/resources/cast-research-labs
LikeLike
Nice write-up. It seems like the key challenge we need to sort out how to overcome, is the the fact that there isn’t time factored into the development life cycle to iteratively evaluate the core technology of a specific product to determine its “staying and growing” power. Instead, development life cycles seem to be solely driven by the feature set. This leads to further piling on of code and a patchwork of fixes and band aids that looks something like a Jenga game…until it eventually falls over. Getting that evaluation into the development life cycle and quantifying the cost/risk of not making adjustments along is key to working toward the reduction of this debt.
LikeLike