The Agile Executive

Making Agile Work

Posts Tagged ‘Cyclomatic Complexity

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.

Advertisements

Paulo Coelho’s Good Counsel to the Agile Champion

leave a comment »

I am already used to the way things are. Before you came, I was thinking about how much time I had wasted in the same place, while my friends have moved on, and either went bankrupt or did better than they had before. It made me very depressed. Now, I can see that it has not been too bad. The shop is exactly the side I wanted it to be. I don’t want to change anything, because I don’t know how to deal with change. I am used to the way I am.

This magnificent paragraph from The Alchemist by Paulo Coelho, captures the nature of the Agile transformation better than any Agile book, article or presentation I had ever read, seen or listened to.  The issue for the team the Agile champion works with is not objectify-ing Cobol, calculating Cyclomatic Complexity or learning how to play Planning Poker. The heart of the matter is members of the team struggle with the innermost feeling “I am used to the way I am.”

I very much doubt that I can summarize Coelho’s counsel on the subject. It would be like trying to capture the wisdom and charm of Saint-Exupery‘s The Little Prince in 500 words or in 140 characters . To fully grasp Coelho’s good counsel, you will need to read The Alchemist cover to cover.