What is Technical Debt? And Does it Affect Me?

What is Technical Debt? The stories occasionally hit the news, a bank’s systems go down, planes suddenly stop flying, wages don’t get paid – technology has functioned for decades but now, suddenly, it no longer serves.

Technical debt is the idea that all development happens from a baseline and, as the code base grows, it becomes less flexible. Whilst not a bad thing in itself, this inflexibility starts to act as a barrier to change and development of the codebase.

Poor code and bugs add to the speed at which technical debt accumulates – but the simple fact is that, as soon as the first line of code is written, technical debt accrues.

Eventually, as illustrated below, unmediated technical debt will render a project unmaintainable. The world around it changes and the code cannot be adapted to keep pace. The budget allocated to any attempt to change or improve is consumed accommodating design patterns and code issues required to accommodate those improvements.

Some technical debt is inevitable. As soon as elements within a project begin to interact and become co-dependent, change becomes harder to implement.

But there are many factors which can contribute to the speed at which technical debt accrues:

• A clear brief is essential – it can be exhausting and dull to specify a custom project in detail, insufficient up-front definition and a poorly articulated statement of the purpose of the project can lead to requirements being defined during the course of development, or development starting before any design takes place. This may appear to save time but can result in profound changes being required before the project is even completed.
• Lack of documentation, where code is created without supporting documentation. This needs to be completed at the code-level (in code commenting) and the project level. The need for creating documentation later represents debt. As memories fade, the longer the issue is left, the heavier this burden becomes.
• Lack of process or understanding, where businesses are blind to the concept of technical debt and make decisions without considering the implications. This is particularly common with inexperienced developers who may not be aware or standard existing means of completing tasks within the build process.

• Tightly coupled components, where functions are not modular, the software is not flexible enough to adapt to changes in business needs.
• Lack of a test procedure particularly at the beta – and ‘guy-in-the-corridor’ – stages it is all but impossible to test one’s own development.
• Lack of collaboration, where knowledge isn’t shared with junior developers or the team at large, the project accrues technical debt because of the work required to merge the changes into a single source base. The more changes done in isolation, the more debt.
• Deferred refactoring; As the requirements for a project evolve, it may become clear that parts of the code have become inefficient or difficult to edit and must be refactored in order to support future requirements. The longer refactoring is delayed, and the more code is added, the bigger the debt. 
• Lack of alignment to standards, where industry standard features, frameworks, and technologies are ignored. Eventually integration with standards will come and doing so sooner will cost less (similar to “delayed refactoring”).

• Business pressures, where the business considers getting something released sooner before the necessary changes are complete, builds up technical debt involving those uncompleted changes. 
• Lack of ownership, when outsourced software efforts result in in-house engineering being required to refactor or rewrite outsourced code.
• Last minute specification changes. These have potential to percolate throughout a project, but there is insufficient time or budget to document and test the changes.

After a Project is Launched

When compared with many software solutions, the environment in which a website runs changes exceptionally fast. Exposed to the entire world, a website is subject to:

• changes in browser standards;
• trends in device use change – witness the move from desktop browsing to mobile devices;
• legal requirements change – GDPR, cookie law;
• supporting technologies change or disappear completely – Google Analytics 3 will be widthdrawn in 2023.

Merely by existing online, a website accrues technical debt, without continued development and support all websites will eventually age to a point where they can no longer be maintained.

Even ongoing developments can add to the debt, long series of project enhancements over time renders old solutions sub-optimal. Factors such as maintaining backwards-compatibility can exacerbate bloat and make the refactoring required harder and more risky. Each project becomes harder to complete as the code base becomes unwieldy.

Technical debt is a challenge in web any development, but proactive strategies can help mitigate its impact. Here are some strategies we, as developers, implement to minimise technical debt:

It is very tempting to dive straight into a new project … but you’ll only do it once.

Even if resources to not permit complete, granular specification of a project technical proposal, you must get a clear brief. If the purpose of the project is clear, the developer team can make informed judgements to keep the project aligned with the final destination.

Nothing contributes more to technical debt than changing specification during development. It obfuscates the intent of the code, making it harder to read in the future (even to the author). It causes unwanted code to be written. Existing code, even when unwanted, is hard to remove for of fear of breaking dependencies (software makes this better, but still …).

Implement thorough code reviews as a standard practice in your development workflow. Encourage collaboration and knowledge sharing among team members.

Emphasise the importance of clean, maintainable code during code reviews. Address any concerns about code complexity, duplication, or deviations from coding standards.

Invest in a robust automated testing strategy to catch bugs and issues early in the development process.

This includes unit tests, integration tests and end-to-end tests.

Implement continuous integration practices to automate the process of integrating code changes. Run tests whenever new code is added to help prevent regression and identify issues promptly.

Regularly update and expand the test suite as the project evolves to cover new features and modifications. This helps maintain a high level of code quality and prevents the accumulation of untested code.

Schedule regular refactoring sessions to address existing technical debt. Set aside dedicated time during development cycles to focus specifically on improving the codebase without introducing new features.

Prioritise and categorise technical debt based on its impact and urgency. Tackle critical issues first to prevent them from escalating into more significant problems.

Communicate the importance of refactoring to stakeholders. Emphasis the long-term benefits in terms of code maintainability, reliability, and faster development cycles.

Remember that addressing technical debt is an ongoing process. Adopting these strategies as part of your development culture can significantly reduce the risk of accumulating debt over time. Regular communication within the development team and with stakeholders is key to maintaining awareness of technical debt and ensuring that it is actively managed.