How to reduce an elephant of Technical Debt

About the photo

What is Technical Debt?

In order to fully understand the impact of technical debt, we must first have a full understanding of the cost of software maintenance. One of the most neglected areas of the software development life cycle is maintenance. As defined by wikipedia.com, software maintenance is the modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment. Over the years the proportion of software maintenance cost of a product has increased from approximately 70% to over 90%. Annual software maintenance cost in the United States has been estimated to be more than $70 billion (Sutherland, 1995; Edelstein, 1993). The cost in software maintenance consists of various types which include perfective maintenance, enhancements, time for developers to understand the code, and legacy systems. Each of these types of maintenance contributes to a complex problem called Technical Debt.

In the December 2009 issue of MSDN Magazine David Laribee wrote an article entitled “Using Agile Techniques to Pay Back Technical Debt”. This article explains techniques on analyzing and making a case for reducing “technical debt”. Technical debt is the expensive costly code that is hard to maintain and error prone. This type of code kills productivity and is difficult to maintain. The question that the article answers is “should we fix technical debt”. One reason to fix technical debt is the long term cost benefit. Test-Driven designs will have a higher initial cost but over time the cost will level out where in a rapid untested coding design the initial cost is low but over time the cost will grow exponentially. The following steps should be taken to formulate a plan to sell to the management team:

1. identify where the debt is
2. build a business case and get a consensus on the priority
3. fix debt with proven tactics
4. find additional debt and repeat
5. After a plan has been formulated and accepted, there is still an extremely hard question that needs to be answered. How do you reduce an elephant of Technical Debt?

How to reduce an elephant of Technical Debt?

So the million dollar question is “How do you eat an elephant?” The answer: One bite at a time. In order to take on an elephant amount of technical debt you must first determine the best way to simplify or divide the problem into manageable pieces. The following steps will help you reduce technical debt:

1. Identify the code that will give you the greatest return
2. Introduce shape
3. Create unit test for the changes made

Identify the code that will give you the greatest return

When identifying the change that will give you the greatest return look for the following signs:

1. Code that seems to produce the most defects
2. Code that is frequently used by users
3. Code that “looks” ugly

After identifying high return candidates, you must evaluate the impact and estimate the return. Once the high return candidate is identified you must begin reducing technical debt by introducing shape to your code.

Introduce shape

There are several ways to introduction shape into your system. The first thing you should do is get a complete understanding of your code and how they should communicate within the system. This understanding will allow you to clearly understand how system components will communicate and it will reveal system coupling. Using your new found understanding of the system, begin organizing your code into namespaces named after the layers of your architecture. As you begin to introduce shape and/or create layers, begin to define rules that dictate which layers are allowed to interact with each other. After successfully introducing shape to your system, you can begin to further solidify your design by creating new projects based on your namespaces. This will allow you to enforce the new shape by controlling the project references. While making these dramatic changes to your system, you must take precautions to protect against the introduction of new defects. Therefore, you must create unit test to exercise the areas that have been changed.

Create unit test for the changes made

There are many unit test frameworks available that will help you to create test to prevent the introduction of new defects. As you make changes to introduce shape, you should also create a group of unit test. If there are any failed test, you must act immediately to address the defect. Not addressing these issue immediately you will reduce the confidence of the management team and stakeholders.