Developing a Strategy for Handling Technical Debt

With time to market becoming the key focus, we are all forced to develop “point-solutions”. We are building new features to our software giving limited thought to solving one particular problem without much regard to related issues.

Invariably enterprise solutions end up with accumulating technical debt.

Technical Debt can be defined as the implied cost of future reworking required when choosing an easy but limited solution instead of a better approach that could take more time.

Technical Debt is crucial; as if not kept under control it can lead to weak architecture, smelly design and smelly code which in turn will impact time-to-market, ability to add new features and cost effectiveness.

Technical Debt may also impact the company’s competitive edge and in an analogy comparing technical debt to financial debt, it essentially prevents a business from growing profits.

?Technical Debt include symptoms of a bad architecture. According to Robert C. Martin these are:

• Rigidity - Rigid software is challenging to adapt because even one modification will inevitably lead to the necessity for other changes.
• Fragility - Fragile software tends to break frequently as a result of a single change. Often, the issues arise in locations that don't relate to the altered environment.
• Immobility- When a design has components that could be used in different systems but would require too much work and danger, it is said to be immobile.
• Viscosity- At this point, maintaining the software's architecture can be challenging. It's more difficult to do the right thing than the wrong thing (breaking the architecture).
• Needless Complexity- This might be the most obvious evidence of poor design. Good software is lightweight, adaptable, simple to read and comprehend, and above all, simple to alter.
• Needless Repetition - The task of modifying software becomes problematic when there is redundant code present.
• Opacity- Opacity is a module's tendency to be challenging to understand. Code that changes over time typically gets harder to know as it does.

Way Forward – building a strategy

Building a strategy for technical debt need not end up the road to modernization but can start with refactoring at various levels of software engineering – including members from the product team, engineering team, devops and even the finance teams (trade-off decisions have to be linked to cost implications) in the overall process. ?Some important aspects to consider for this strategy would be a refactoring goal into the product backlog, putting in accountability for architecture debt and drift, utilizing well architected framework guidelines or tools and adding in various methods for clean design and code.

It is an investment made better sooner than later.