DevOps Zone is brought to you in partnership with:

Israel Gat ("agile_exec") is recognized as the architect of the agile transformation at BMC Software. Under his leadership, BMC software development increased Scrum users from zero to 1,000 in four years. Dr. Gat currently focuses on technical debt, large-scale implementations of lean software methods and devops. Israel is a DZone MVB and is not an employee of DZone and has posted 36 posts at DZone. You can read more from them at their website. View Full User Profile

Should You Ship This Code Before Reducing Technical Debt?!

  • submit to reddit
Technical debt is usually perceived as a measure of expediency.

Control flow graph of function with loop and an if statement without loop back.svg

Source: JulesH, Wikipedia, A control flow graph of a simple function

You borrow a little (time) with the intent of paying it back as soon as possible. To quote Ward Cunnigham:

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… I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.

As is often the case with financial debt, technical debt accrues with compound interest. Once it reaches a certain level (e.g. $1 per line of code) you stare at a difficult question:

Should I ship this code before reducing the accrued technical debt?!

The Figure below, taken from An Objective Measure of Code Quality by Mark Dixon, answers the question with respect to one important component of technical debt – cyclomatic complexity. Once complexity per source code file exceeds 74, the file is for most practical purposes guaranteed to contain errors. Some of the errors in such a file might be trivial. However, a 2007 study by Capers Jones indicates about a third of the errors found in released code are likely to be serious enough to stop an application from running or create erroneous outputs.


To answer the question cited above – Should You Ship This Software Before Reducing Technical Debt?! –  examine both cost and risk for the number of error-prone files you are about to unleash:

  • The economics of defect removal clearly favor early defect removal over late defect removal. The cost of removal grows exponentially as function of time.
  • Brand risk should be first and foremost on your mind. If complexity figures higher than 74 per file are more of the norm than the exception, you are quite likely to tarnish your image due to poor quality.

If you decide to postpone the release date until the technical debt has been reduced, you can apply yourself to technical debt reduction in a biggest-bang-for-the-buck manner. The analysis of complexity can identify the hot spots in your code, giving you a de-facto roadmap you would be wise to follow.

Conversely, if you opt to ship the code without reducing technical debt, you might lose this degree of freedom to prioritize your “fix it” work.  Customer situations and pressures might force you to attend to fixing modules that do not necessarily provide as much bang for the buck.

Postscript: Please note that the discussion in this post is strictly limited to intrinsic quality. It does not address at all extrinsic quality. In other words, reducing/eliminating technical debt does not guarantee that the customer will find the code valuable. I would suggest reading Beyond Scope, Schedule and Cost: Measuring Agile Performance in the Cutter Blog for a more detailed analysis of the distinction between the two.

Erratum: The figure above is actually taken from a blog post on the Mark Dixon paper cited in my post. See McCabe Cyclomatic Complexity: the proof is in the pudding. My apology for the error.

Published at DZone with permission of Israel Gat, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Stephane Vaucher replied on Mon, 2011/09/19 - 8:46pm

Although I fundamentally agree with your message, there are some problems with the 'facts' you are using. First, please do not quote a technical paper by a company. It contains many fundamental issues that most scientifically peer-reviewed paper would not have. A simple example, is that the experiment does not control for the period evaluated and for size. Second, statements like 'The cost of removal grows exponentially as function of time.' are somewhat misleading. As bugs are removed, the marginal cost of removing an additional bug increases. That is what lead to the assertion that there is some sort of super linear function that describes the cost of bug finding. I'll give you an example of why this is misleading. If you have a 100,000 needles in a haystack, you might actually find one. If you already found 99,999 needles, finding the final one is a lot harder than finding the first one (by a factor of 100,000).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.