Accumulating debt has always been a worrisome scenario, especially in situations when people are forced to take out even more loans in a bit to cover the payments of their existing debt. Just like the financial world has accumulating debt and the debt trap, so does the software industry. If you have been in the industry for a while now, you must have come across the term, ‘technical debt’. Also called tech debt, code debt, or design debt, the term refers to the implied cost that a business incurs when they do not deal with problems that will affect them in the future.

Understanding Technical Debt

Technical debt is the result of prioritising the speedy delivery of a project over writing perfect code. Stemming from the “build now, fix later” mentality, it describes what results from situations where development teams take actions like delaying or omitting work, delaying features or functionalities, cutting corners, or settling for suboptimal performance, so project delivery can be expedited. Technical debt must be paid back later as accruing tech debt only causes existing problems to get worse with time and the longer it builds up, the costlier it gets to fix it.

Types of Technical Debt

Over the years, there have been several ways of classifying the types of technical debt that can be accrued. In 2007, it was simply classified into two types - intentional and unintentional technical debt. Later, technical debt was given 4 categories, which took intent and context into consideration to classify debt as deliberate or inadvertent, based on the intent, and further as reckless or prudent, based on context.

These proposed categories were dismissed in 2014 in favour of a categorisation that addressed the nature of the debt that was incurred.

1. Architecture Debt

A short-term expedient approach to design or construction, this type of debt creates a technical context where the same work requires architectural rework. Factoring in the increase in costs over time, it proves to be more cost-efficient to deal with the rework now rather than later.

2. Build Debt

This type of tech debt is incurred as a result of issues that make building tasks more time-consuming and difficult. For example, there may be ill-defined dependencies or code that do not really add value for the end user in the build process, going through which unnecessarily slows down progress significantly.

3. Code Debt

This is caused by the prioritising of speed over perfection and involves the actions that are taken by the developers to expedite project or functionality delivery. Inconsistency in style, coding guidelines violations, and code smells are some o the primary causes of code debt.

4. Defect Debt

Defect debt occurs when the short-term benefits of delaying bug fixing wins over the long-term consequences of postponing these activities. In sprints to ensure quick and speedy product launches, some defects are intentionally left as technical debt, which should ideally be taken up in the next technical debt cycle.

5. Design Debt

Also known as UX debt, this is incurred when tight timelines or impractical project constraints are forced on researchers and designers. Meeting release dates is possible in the short-term but with time, choosing shortcuts over and over again leads to compounding user experience issues. This debt is particularly common with Agile teams that are under the heightened pressure of regularly announcing new product features and capabilities. Regardless of development methodology, UX or design debt can be incurred by any project and if left unaddressed, it can lead to a loss of traffic, trust, and revenue.

6. Documentation Debt

Every development project begins with an initial concept, which is modified, upgraded, changed, added on to, etc. This makes proper documentation of the project extremely crucial and non-existent, inadequate, or incomplete documentation can lead to problems that can be referred to as documentation debt.

7. Server Infrastructure Debt

Technical server infrastructure debt is incurred because of incompatible, inadequate IT components. As this aspect involves the maintenance and refurbishment of existing infrastructure, several times, business leaders are unable to understand the concept, rejecting calls for upgrading server infrastructure citing it as being expensive with no significant ROI.

8. People Debt

This type of debt is incurred because of the human factor involved in the development process. Some of the most common reasons that lead to the accumulation of People Debt include a lack of proper guidance for the developers, unrealistic timelines or impractical budgets, lack of expert resources, improper communication, etc.

9. Process Debt

In general terms, it can be said that process debt is anything that is different or inefficient as compared to what the development team would consider to be an ideal workflow, environment, and process for a certain project. Choosing a limited approach and implementing suboptimal tech solutions to meet an immediate need tends to compromise efficiency in the long run.

10.  Requirement Debt

Requirements refer to a description of the software, how it should behave, its functionalities, constraints, and other attributes to define the ideal value of the project. If there is a gap between the initial requirements and the actual implementation of the system. It is caused when shortcuts are used for short-term benefits, which may appear as missing, incorrect, or delayed features of the project.

11.  Service Debt

This type of tech debt can be driven by business or technical objectives, occurring because of inappropriate selection/substitution of web services. Incorrect web services lead to a mismatch between the applications’ requirements and service features as well as the under- or over-utilisation of the system. This tech debt is relevant for service-oriented system architectures.

12.  Test Debt

This refers to the issues that affect testing activities and processes, which affect the quality of the testing being performed. Planned tests that were not implemented, known inadequacies in test suites, using the same testing process at all stages of development, etc. can all lead to test debt.

13.  Test Automation Debt

In regular, fast-paced deployments in a project, test automation is crucial for maintaining delivery speed while also ensuring quality. Without automated tests for different stages of development, progress will slow down, and delivery will be much more complicated. Test-driven development can even help reduce technical debt created by other aspects of the project.

The Proper Management of Technical Debt

Having certain practices in place can go a long way in helping you deal with technical debt. Some of the best practices for tech debt management that you can consider for your development processes are:

Track and Remove ‘Cruft’

Tech debt is not a one-trick-pony and can survive multiple development cycles:

• Inventory: Create a list of technical depts throughout the organisation and religiously keep track of the instances where intentional debt is created and of all deliveries that need rework in the coming times.
• Categorise: Based on the complexity, potential impact, and cost of fixing, group technical debt into manageable units.
• Appraisal: Define the impact, effect, and consequences of ignoring each unit, which will help you prioritise tasks.
• Share: Make this information and documentation accessible to all relevant stakeholders in the development team as well as in the organisation.
• Get Rid of Cruft Early & Regularly: Instead of waiting for a pile-up, schedule regular cycles for debt clean-up.

Build a Team of Skilled Developers

‘Value over money’ and ‘Quality over quantity’ – these should be your mantras when it comes to hiring developers. It is a fact that a smaller, better-skilled team will operate much better as compared to a bigger team with underperforming coders. If you account for the revenue that is lost because of the inefficient performance of your product/feature, the extra cost of hiring skilled and experienced developers will seem nominal.

Ensure Code Quality

Create a style guide for coding and document ideal coding practices to make writing cleaner syntax easier. Measuring quality metrics like cyclomatic and cognitive code complexities, class coupling, number of lines of code, depth of inheritance, arity, maintainability index, Halstead complexity measures, etc. can help you monitor the quality of code that is being written.

Automate Testing Processes

Manually testing code is not sustainable in the long run for uncovering cruft and tech debt. The time and effort that it will take to automate testing will be much less than the time you lose at the ‘testing bottleneck’.

Maintain Transparent, Detailed Records of Changes

Keeping ongoing records of changes being affected in a repository, so if any problem should arise, it will be extremely easy for a developer to trace the source for documenting debts. Documentation of this kind also proves to be extremely useful for highly complex projects and distributed teams.

Create a Dedicated Team

Tech debt decisions should not be public domain, taken randomly by a myriad of developers. Decisions should be pondered, taken, and implemented by qualified team members who not only have product trade-off experience, but also understand the project in question.

Factor Time and Resources for Tackling Tech Debt

Ensure from the very beginning that your team has enough time and resources to reduce tech debt. Regular code refactoring is crucial for the continuous management of tech debt, but it is also quite time-consuming. If developers face constant pressure for deliveries, they will not be able to tackle tech debt, so allot around 20% of their time in a sprint cycle for debt refactoring.

Tech debt can cause a lot of damage if left unchecked. As long as your team understands the necessity of repaying technical debt well in time, the occasional trade-off of quality for speed can bring in a competitive edge. All you need to do is to use tech debt wisely and ensure that it is proactively managed to avoid roadblocks down the road.

Bio: Having 15+ years of experience in technology management, team management, project management, delivery management and process management. Working with Microsoft Technologies, Sitecore CMS in the Automobile Domain, also have experience in design and development of the Lead Management Systems, HR Management Systems, Campaign Management Systems etc. Good exposure in Azure and AWS infrastructure, creating the proposals, SOP's, various tools selection and implementation.