Storage Informer
Storage Informer

Agile Best Practice (3 of 10) – Measure and Frequently Repay Technical Debt

by on May.28, 2009, under Storage

Agile Best Practice (3 of 10) – Measure and Frequently Repay Technical Debt

Technical Debt is a popular term amongst Agile practitioners. Ward Cunningham characterizes technical debt as follows:

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, object-oriented or otherwise.

What is Technical Debt? Technical Debt is loosely defined as the volume of poorly written lines of code, poorly refactored, not following coding standards, not supported with sufficient unit tests, and the amount of code duplication. Technical Debt eventually leads to un-maintainable code and non-robust solutions. For the end customer, this usually always leads to defects (post-production). Customers are happy as long as their functionality they asked for works well. However if the underlying code base is not robust enough, as time passes, this leads to more issues and things become more chaotic. Customers quickly start losing trust with software development teams. This is not good for SW teams as it leads to frequent fire fighting activities and team gets worn out as well.

How is debt accumulated? Technical Debt is easily accumulated if the developers are not very disciplined about writing good quality code. Deadlines only make the problem worse. If they&aposre not careful, developers can easily tend to take short-cuts (sacrifice quality). They may run out of time to refactor their code, they may run out of time to write good quality unit tests.

Measuring technical debt is very important (remember the adage -> you cannot fix what you cannot measure). This helps you determine the criticality of the problem and also helps you negotiate the scope of future releases with your customers. For example, if you and the customer mutually agree to an acceptable threshold level of technical debt (e.g. 500) and if it goes above the threshold level, this means that you can negotiate to swap a new requirement with a technical debt repayment effort.

How do you measure technical debt? In our team, we&aposve come up with a way to measure technical debt (its not perfect, but works well for us). We classify technical debt into 2 portions – bug debt and code debt. Bug Debt is a normalized score of the number of post-production defects reported by users / customers based on their severities (e.g. Show Stopper issues get a higher penality compared to Low issues). We also normalize the penality based on the age of the issue / defect. For example a SS issue open for 10 days costs a much higher penality. Each day a penality is accrued. Code Debt is measured as a normalized score of percentage of unit test coverage and code duplication (you can include cyclomatic complexity here as well). We also look at a subjective assessment of code base – coding standards adherence and a measure of maintainability.

Bug Debt: We use a tool like TFS (Team Foundation Server) to list the number of open post-production defects. We use the chart below to determine an overall normalized score for the bug debt. Here is a chart we use:

If a SS issue is open for less than 7 days, it gets a penality of 40 points. If its open for more than 60 days, it gets a penality of 100 points and so on. We look at the number of days open for each defect and then calcuate the total bug debt score.

Code Debt: We set goals for code coverage through unit tests and code duplication. Usually tools like TFS, Cruise Control, Simian can measure the code coverage and code duplication (as-is state). We determine the variation from the goal (e.g. if 50% is the goal for Unit Test coverage, and if the as-is happens to be 40%, then we assign a penality for 10% variance. We also do a subjective assessment of the code quality (how well is the code written) – what is the probability and impact that it will be harmful for customers – based on this we provide a score.

We report the technical debt on the 1st and 15th of each month. Here is a chart of how our technical debt has progressed in the last 1 year.


:, , , , , , , ,

Leave a Reply

Powered by WP Hashcash

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!

Visit our friends!

A few highly recommended friends...