In today’s rapidly changing business milieu, it’s critical to meet the dynamic business expectations, thus necessitating IT agility and flexibility. This accentuates the need for a broad based, integrated software development capability to manage the burgeoning business complexity – and thereby help CIOs/CTOs keep their worries at bay. In recent times, the term ‘Technical Debt’ has started to emerge as one of the most widely used buzzwords among the CIO fraternity.

Technical Debt describes the obligation incurred by a software company when it selects a software design approach that’s beneficial in the short term, but increases complexity and cost in the long term. Eventually, this will lead to an exponential increase in costs, to redesign/correct the software – reason enough to prompt CIOs the world over to take note of this parasite in their IT applications. Increase in the agility of software releases in the recent past signifies this development.

Research indicates that, of late, the base product is reworked almost every fortnight to accommodate new features and releases, leading to poor structural stability of the software. Owing to some short term decisions taken by organizations at the software development stage, many of them are bearing the brunt today. Prevalent causes of Technical Debt include poor coding and system design, inter-team and intra-team communication and collaboration discrepancies, lack of standard development protocols and poor requirements’ identification and specification.

This can have serious repercussions for an organization – ranging from poor customer responsiveness to long delivery times; an abnormal proliferation in defects to disgruntled, poor performing teams. In addition to being dependent on one particular vendor, this can lead to poor agility and loss in market share. On one hand, in-house innovation may come to a complete standstill; on the other, the overarching objective will be to maintain status quo. That said, one tricky thing associated with Technical Debt is the lack of a definitive way to measure it effectively.

Overcoming Technical Debt

Pre-empting or overcoming Technical Debt is a comprehensive exercise in itself. It’s about dealing with the unknown; it involves changing the internal structures submerged within the software architecture/framework. In reality, two aspects get manifested - the defects; and a higher time to effect a change. Organizations report that, as high as 30 to 40 percent of defects in software products can be attributed to poor internal structures. The methods and models in vogue haven’t really helped in controlling this debt.

Let’s try and draw an analogy to better understand this paradigm. During the advent of horseless carriages (read automobiles) in early 20^th century, “Stop” and “Give Way” sign posts emerged. These signs were critical to ensure that the traffic system is self-sustained even in blind spots. The same approach holds good for our software structures as well, albeit holistically. The key is to start with upstream processes like requirements and architecture - and not just focus on the code alone. Most high impact issues in software products can be attributed to poor requirements’ structure and architectural decisions. A measurement framework to assess the completeness and correctness of requirements, coupled with the evaluation of architectural decisions, is a good starting point. This enables the discovery of potential vulnerabilities with both the development teams and the management getting a sense of the magnitude of risks involved. This visibility helps bring in a better structure into the software being developed.

As we move down to the design and implementation phases, measurability improves. Many tools provide the ability to measure design and complexity aspects in code. Programmers need to be equipped with the static analysis measurement tools integrated to their development environments.  A code with higher complexity levels and coupling is prone to be highly defective, with low maintainability. As the code gets integrated, profiling of the entire application can show the aspects of performance, security and maintainability upfront. Statistics at the application level would give an abstract view of interconnected issues, which a program level code metric cannot provide. Thus, a comprehensive measurement framework that covers all engineering phases and the product as a whole, will help in ascertaining the Technical Debt - which is otherwise unknown - in a manner that a business analyst or a technical person can understand and relate to.

More visibility empowers development teams to take timely action. One of the best practices is to budget a time for refactoring with each instance of iteration. This practice ensures the flexibility to weave in some more pieces into the development cycle, while adhering to the pre-set protocols. Two other key elements are: enabling developers on best in class engineering practices; and dealing with change in behaviour of the senior management. Most developers are crunched for time, compromising on the internal quality of software. When repeated over a period of time, this becomes a monster lurking in the dark, accumulating technical interest all the while. Management should walk the talk and lead the change towards this broader mind set; and developers, architects and business analysts need to inculcate the right engineering practices to deal with Technical Debt.

Nevertheless, software engineering practices have indeed come a long way. Just like how doctors are equipped with a blood analysis report for delving deep and identifying the symptoms, the software industry is steadily adopting a similar approach. With more maturity and a broader mind set, a software company can definitely overcome the Technical Debt syndrome to build best in class software that provides higher agility in a sustainable fashion!

The writer works as Practice Manager for Quality at Collabera Solutions.