Technical Debt- Manager's perspective

This is the second article on technical debt and looks at Technical Debt from a Manager’s perspective. Click here for the first one. It helps if you read the first article before you proceed with this.

To start with, a few points on technical debt that are obvious.
    # Technical Debt is bad and should be treated like normal financial debt
    # Normal practice must be to do good design and write good code (as expected by the definition of good software).
    # If your system incurs technical debt, it should be for a genuine reason and at the first chance, the debt should be serviced.

#1 It is perfectly possible to write code/create an software product without incurring technical debt. This should be the aim of any project manager, software architect and developer.

#2 When you have to incur technical debt, out of the four quadrants of technical debt  as categorized by Martin Fowler, the quadrant Deliberate/Prudent is acceptable.

Types of technical debt. (image courtesy- Martin Fowler’s Site)

For people who question this decision to call only the Deliberate/Prudent quadrant as acceptable, I request them to look into the explanations given in each of the quadrant. Going through the explanation makes it clear that other quadrant technical debts don’t conform to the definition of creating good software. If a person's idea of Technical debt falls in the other quadrants, you can be sure that people are using the term technical debt to hide their ignorance or incompetence or just being un professional.

#3 There is one exception to the above definition/rule..If as a manager, you/your company has taken over a product with a messy code base. In such a scenario, I believe it is ok for people to use the word technical debt to quantify the effort involved (which can be translated into a $ value) to bring back the quality of the code base in line with the definition of good software.

#4 Technical debt should be one of the key factors that influence a decision when a company wants to acquire a software product.. the reason for it's importance is explained in #5.

#5 If an entity(manager/company) takes over a product without factoring in technical debt, but later realize that that the product has high technical debt, this makes faster code changes, easier testing and hence faster releases difficult.

Then one of the following options have to be choosen from.
#5.1 Pay back the technical debt along with interest in a single go – this is usually not a viable proposition economically as the product may have to go without any new releases for the whole duration the debt is paid back.
#5.2 Gradually payback the technical debt and improve the quality of the product. – this makes more of a commercial sense as the debt is paid back in smaller chunks and the quality of the code base keeps increasing. On the flip side, this approach takes a longer period of time.
#5.3 Else retire the product, if the above options aren't possible, since maintaining it is no longer an economically viable solution.

#6 Cost of NOT serving technical debt is more than Cost of Serving technical debt: Taking the definition of good software product (as any software that can be modified and tested, with minimal effort), the cost of servicing the debt typically will include fixing the coding standard violations, refactoring the design and code, taking care of cyclomatic complexity and in- adequate test coverage.

If a person looks at the cost of not servicing the technical debt, this will include the following.
    # Additional overhead on customer support.
    # Executive time spent in managing un happy customers
    # Opportunity cost of missed releases
    # Loss in market share due to less frequent releases
    # Impact on market share,
    # Intangibles like loss in reputation
Since the cost of servicing as well as not servicing has an impact on RoI , a company should consider technical debt as a key parameter to arrive at an informed decision when it comes to evaluating a software.

#7 Cost of Change for Products with Technical Debt. Let us look at the product life cycle of an optimal software product (as defined by software that can be modified and tested with minimal effort) and a software product with high technical debt.

The cost of change for a product with high technical debt is more compared to an optimal product , as shown in the diagram below.

CoC and Customer Interest Vs Time

Please note that here we assume that the optimal product as well as the product with high technical debt both continue to get enhanced for the same amount of time. This is not true in reality as we will further see in the article. The reason why the customer interest in the product keeps decreasing is that the higher cost of change makes it more difficult for new features  implemented and at a faster rate.

#8 Longevity of a software product with higher technical debt is actually lesser compared to the optimal software product ( as explained in the graph below). This is because the product is never allowed to mature feature wise and also as the higher technical debt makes it difficult to keep it alive. This mostly results in early retirement of the product.