Accounting for Technical Debt

We’re hearing all about debt nowadays. Consumer debt, corporate debt, government debt… the list goes on. As professionals operating in a software engineering environment, there’s an additional type of debt of which we also need to be mindful.

Technical Debt

Per Steve McConnell:

The term “technical debt” was coined by Ward Cunningham to describe the obligation that a software organization incurs when it chooses a design or construction approach that’s expedient in the short term but that increases complexity and is more costly in the long term.

Follow Steph adds:

Developer Debt means taking the quick and dirty way today knowing that tomorrow we’ll have to pay more to fix the issue because it will have evolved into a bigger problem, hence the idea of debt with interest.

In Cunningham’s own words:

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…

I think one of the contributing factors (among many, all of which I won’t go into here) to increasing technical debt is the fact that business owners often don’t understand or appreciate it. Here’s a quick, hypothetical example. You give the business owner 2 choices:

• Option 1: Can hard-code at every opportunity, use a few existing database attributes for purposes other than those for which they were designed – this will help us save the time it would take to add new rows.  We could cut a few corners on normal conventions for formatting and commenting code. We can also just slide the functionality into system “B”,  even though we plan to retire it within the next few years, and system “A” is the one better suited for it. We would have to wait another 7-10 days before the system “A” developers wrap up work on another project. The hard-coding is throw away, of course, and cutting corners on the rest of it is going to make it much more difficult for developers that have to go in and make future modifications, but this path will get you your product in 2 weeks.

• Option 2: Can provide an architecturally sound and scalable solution with clean, commented, and reusable code. We’ll need to wait a little longer for developers for system “A” to become available, but that is really, according to the longer-term architectural vision, where this functionality needs to go anyway. This path will get you your product in 10 weeks.

In many cases, your stakeholder probably didn’t hear a word until the last sentence of either option. At that point, of course, s/he wants the faster option.

Again, per Follow Steph:

It’s much easier to implement a quick fix today and ignore the longer term costs because we’re dealing with today, with this quarter, with this release, with now.

Or, imagine your business sponsor thinking: “Not only will the cost of developing it be cheaper, but we’ll begin to benefit earlier from the new functionality! We can realize our ROI for the project way sooner! I don’t care about the whole ‘clean code’ or ‘architecturally sound’ stuff, anyway, as long as the functionality meets spec! That’s all stuff for IT to worry about. Hey, I might even get a raise out of this!”

Ok, so that last bit was a slight exaggeration and to poke some fun, but you get the point.

Using the Analogy

I really like “technical debt” as an analogy/metaphor. It’s something that the non-technical business stakeholder can understand and appreciate. As with our own personal finances, we can do it the right way and pay for it now, or we can do it the quick and easy way and pay for it later with interest.

As a business analyst, I see it as my job to clearly communicate the fact that exactly like card or loan debt, “interest doesn’t sleep” and it compounds over time. What started out as a small expenditure can eventually end up costing a great deal, and can limit our ability to make further improvements later.

Now, to be very clear, my intent in bringing the notion of technical debt to your attention is not to give the impression that we always need to do things the longer, better, more expensive way first. In a perfect world, we’d always have plenty of time, people, and money to “pay with cash,” but such is not always the case. In the real world, sometimes the quick and dirty way is necessary.

In either case, an analyst’s charge is to help business decision makers make educated decisions based on the available options, and to understand the potential ramifications of those decisions. We do this by presenting  the options, trade offs and corresponding risks in clear terms that they can understand and appreciate.

Enough out of me..

Do your stakeholders understand the notion of technical debt? Have you ever used that term to describe it? What are some other analogies that you’ve found effective in making technical things seem not-so-technical?

Also, I touch only very lightly on the concept of technical debt. Please do go back and read these articles for the more deeply developed analogy, and some other interesting sidebars.

Additional Reading

Here are some of my bookmarks on technical debt that I’d highly encourage you to read if you’re interested in the concept and want to understand it in greater detail.

• Steve McConnell’s 10x Software Development – This is probably my favorite of the articles. McConnell goes quite a way in developing the debt metaphor, and even provides a taxonomy for technical debt. For this article, you really have to read the comments, where even Cunningham, himself, weights in to get the full benefit.
• The WyCash Portfolio Management System – This is Cunningham’s original article. Interestingly, it isn’t an article on “technical debt” per se. Scroll down to paragraph 5 for the bit on technical debt.
• Developer Debt at Follow Steph also provides a lot more meat to the debt analogy, including a graphic that illustrates that how incurring developer debt can lead to a point where “nothing can done in any reasonable time or method.” Again, the comments are well worth a few minutes to skim.
• On Technical Debt – Revisiting the Technical Mortgage – Really develops the analogy of technical debt as a “mortgage” of sorts.
• Martin Fowler on Technical Debt is a brief, but worthwhile read on technical debt.