Restructuring Technical Debt

Technical Debt     metaphor 

[synonym: Code Debt] [types: Accidental, Deliberate, Inefficacious, Unavoidable]  

Refers to:

1. Consequences arising out of Poorly Written Code, Non-Modularization, Incomplete Documentation or Under Par Test Coverage
2. Intentional Decisions made while developing code, to speed up development,  but knowing that these will have to be changed later.
3. The extra effort that has to be done to improve the software or to add additional functionality.

Most common perspective on Technical Debt implies, its genesis from hit and trial methods (Collocations: inefficiencies or lack of knowledge) followed by development team, in an attempt to achieve faster results.

Technical Debt is also leveraged consciously -- Borrowing Efficiency now to achieve faster GTM, in exchange for having to do more work to mend and improve the code later.

Similar to capital borrowing, the technical debt also gathers interest. In simple words, you will pay more, if the business is not achieved or business cannot be serviced due to technical glitches.

Imagine using Kitchen (Code Base) to cook everyday (New Features), but leaving without cleaning (Poor Documentation, Low Test Coverage, Non-Modularization). Beyond a point, the Kitchen becomes chaotic and it eventually becomes impossible to cook, leading to setting up another Kitchen or Deep-Cleaning the Kitchen, resulting in excess costs.

The Magical Key: Reporting Technical Debt

Another perspective comes from Gartner that proposes measuring and defining technical debt as a method, to improve business plans.

CIOs either need to recover from past or prevent future underinvestment, as new cost liabilities are continually added to the technology portfolio. Report cost liabilities to identify your technology debt position, then develop business plans that create net wealth, not just debt.

Technical Debt can lead to:

Cash Costs including recruitment of more resources to maintain the system, or excess time required to correct rolled-out features, or build new features. 

Non-Cash Costs like frequent breaks in user-experience, or inability to improve feature delivery, or keeping up with competition. 

Loss of Sales due to glitched performance like system outages due to frequent feature roll-out or roll-backs.

Lack of Data Delivery Design resulting in lower levels of productivity, due to significant amount of time spent on extracting and analysing data.

Restructuring Technical Debt 

Factors which raise the risk of Technical Debt and may required to be diligently thought through during various stages of development cycle are:

• Code Choices which may be amateurish, (as the original code may have been written as an experimental project), or unmaintainable (written by a small cohesive team with clear vision of the smaller problem they were tasked to resolve). As the business evolves, development teams grow in size and are often divided into separate groups, in order to manage and merge complex business use cases into the code. This may often result in separate teams working in some degree of silos. Building a responsible and responsive team with diverse skill-set, ensuring adequate documentation, retaining the talented resources who have clear vision of the product scope, may just be few good failsafe options.
• Dependencies on technical decisions that stitches the code base to technology stack. Over time, the upgrade path may become convoluted, as technology stacks (or versions) become a liability due to lack of stability, expensive or hard to find expertise to manage, end of life-cycle. This situation arises out of lack of planning or foresight or expertise. Its always best to focus on small number of well-known technologies and follow an informed technology adoption process.
• Features that Resist Change. Over a period of time, the problem that we are trying to address, and our understanding of the methods or logics applied to address the problem, will change inevitably. Whenever this stage is reached, some part of our code becomes wrong, i.e. a liability, and needs improvement. Categorizing the Goals into development project stages, and generating a Modular Code Base often helps teams to identify and expunge the incorrect code behaviour quickly. 
• Maintenance Requirement. All code bases need maintenance, resulting in opportunity costs viz. effort and time. Higher maintenance requirement can also occur due to poor conceptualisation, or bad development practices, or lack of documentation. 
• Operability selections that resist change. Should we stop making frequent changes, if these cause site to go down every time a change is made? If metrics are not measured, the changes cannot be deployed confidently. If testing practices and environments are unstable, extensive coordination will be required for a release, and also for the roll-back in the eventuality of a bugged release. All these provide substantial data for development teams to improve practices. If the environments need constant improvement, impacts on feature roll-outs are often discovered the hard way, which impacts the development team’s productivity as well as costs.

Reducing Technical Debt

The faster the resolution, lesser are the interest costs. Development Teams can fine-tune the following approaches to reduce technical debt:

• Prioritise: Issues that may have a chain impact should be the quickest to contain. Allowing the issues to Accumulate is Hara-kiri
• Technology Update: Update to stable builds of the frameworks, application servers, databases etc. is critical.
• Refactoring: Refactoring codes can be very useful to eliminate the possibility of duplicate code. This also helps achieve the modular code base which allows the development team to constantly add to existing architecture.

Apart from the above methodologies suggested for reduction of technical debt, the development teams should also follow the process of compiling the product backlog as a user story and prioritising. The prioritisation log should also list the impact of not managing the identified technical debt factors. As a best practice, development teams should categorize the issue as critical on basis of the spike value of associated technical debt.

Please feel free to engage on this and much more in Information Technology, by writing to me on [email protected] or [email protected]