Advertisment

Technical Debt: Better to be safe than sorry

Technical debt is ad-hoc way of writing software code in an attempt to meet timelines to launch a product faster in the market and raises concerns like high maintenance cost, loss of market share and loss of employee morale

author-image
Pratima Harigunani
New Update
ID

INDIA:

Advertisment

By Sravan Kumar

In today’s aggressive software development world, many a time best practices are compromised pledging to fix it later so as to meet tight project deadlines. Technical Debt represents the effort required to fix problems that remain in an application that is released in the market with codes that may meet the short term expectations but may not be the best solution.

Technical debt is ad-hoc way of writing software code in an attempt to meet timelines to launch a product faster in the market. The business later has to face long-term consequences of poor software architecture and bad coding.

Advertisment

There is a growing concern on tech debt due to high maintenance cost, loss of market share and loss of employee morale. It is visible through the trends such as contracts carrying application performance as acceptance criteria or clients undertaking code review - sometime even engaging 3rd party as necessary - as a part of product acceptance.

A quick internal survey done recently showed that about 48 per cent of clients are conscious of technical debt and expect Code Quality. This is significantly higher than the number seen in the past. This makes it essential for every IT organization to identify and control the debt in a periodic and structured manner.

Manual code reviews are cumbersome, error-prone and hamper productivities. Static code Analyzers have played a key role in automating the code reviews for structural aspects.

Advertisment

Some of the key features of Static Code Analyzer relevant for a Service Provider are given below:

1. An Overall Health Indicator of the application which can give a quick indication to the stakeholders on its health.

2. Ability to support multiple technologies and connect to multiple repositories: This is important in the context of service provider working with multiple clients and hence varied environment.

3. Exclude Code: In case of maintenance projects, bulk of the code is inherited from the client and service provider adds his own. The tool should be able to support quality measurement of the delta code added as different from the overall health of the application.

4. Robustness of rules: Code Quality impacts multiple aspects of software such as maintainability, performance and security. Rules are also many, each of them addressing one or more of these aspects. The extensiveness of rules applied by a static code analyzer is an indicator of the quality of static code analyzer.

5. Prioritization: While rules are many, Pareto principle applies here - there are vital few and trivial many. Not all violations carry the same debt. Ability of the tool to help developer prioritize the vital few will help.

6. Customizability of Rules in case of project-specific or client-specific requirements, ability of the tool to support the same.

7. Drill-down of violations and hence technical debt to class and function levels will help optimize rework effort within the organization while addressing technical debt.

8. Ability to compare the Code Quality across multiple projects helps organization standardize better and learn from each other.

9. Trend analysis of technical debt would help provide a feedback to the engineering team on the results of rework.

10. Periodic automated status update to the stakeholders

11. Aided diagnostics – Tool provides insight into the violation, long-term impact of the same and educates the developer pm the value-add of fixing it right away.

12. Technical Debt calculator – An indicator of the Technical debt either directly in $-terms or in terms of efforts e.g. person-days, person-months etc. Though attractive, the accuracy of this is constrained by the approach adopted in measuring rework effort and assumptions on $-cost of effort

Static code analyzers do add significant efficiencies to the defect detection process. However, it can’t be ignored that the very process that is automated is “Appraisal Cost” which in-turn generates “Rework Cost”, all of them being a part of “Cost of Quality”.

Advertisment

We developed an in-house captive Static Code Analyzer in one of the significant efforts to contain technical debt. We also measured increase in rework cost to address the violations (Technical Debt).

Defects detected resulted in a six per cent addition to the existing rework cost. However, very quickly the team learnt the right ways of coding and this incremental rework cost was eliminated, now coupled with 90 per cent lesser code violations as compared to the initial baselines.

While technical debt may be difficult to eliminate altogether, it can still be minimized through good coding practices. Education coupled with a good static code analyzer optimizes the Cost of Quality with the right mix of prevention and cure (appraisal and rework costs). It delivers process efficiencies for the short-term while balancing with the less measurable but long-term benefits of application health.

(Sravan Kumar is Head – Quality Function at Blue Star Infotech. The views expressed here are solely of the author and do not necessarily represent those of Cybermedia.)

developer experts