The Agile Executive

Making Agile Work

Posts Tagged ‘Ward Cunningham

Jim Highsmith on the Financial Implications of Technical Debt

leave a comment »

Jim Highsmith launched his new blog/website last week. I have no doubt whatsoever it will be a thought leadership blog. Moreover, knowing Jim I would expect the blog will address and integrate concepts and ideas from numerous disciplines, not “just” from software methods.

Jim’s first publicly available post  – The Financial Implications of Technical Debt – explores the impact of technical debt on capitalization. To quote Jim:

So the bottom line for technical debt. It’s expensive to fix, but much more expensive to ignore. Technical debt reduces future earnings, but even more critically, it destroys predictability which in turn impacts market capitalization in the near term, not in the future.

http://www.flickr.com/photos/johnwardell/80125882/

Figure 1: Loss of Predictability

Jim’s post nicely closes the {financial –> technical –> financial} loop. Ward Cunningham’s original debt metaphor borrowed the financial term to apply it to software development. Jim is now bridging from the technical arena back to the financial world.

If you are into any form of agility – technical, managerial or business – you owe it to yourself to follow Jim’s blog.

Written by israelgat

November 1, 2010 at 6:44 am

Should You Ship This Code Before Reducing Technical Debt?!

with 8 comments

File: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

Technical debt is usually perceived as a measure of expediency. 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.

mccabegraph.jpg

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.

Follow

Get every new post delivered to your Inbox.

Join 36 other followers