The stories occasionally hit the news, a bank’s systems go down – the technology as remained unwritten for decades and now it no longer serves.
Technical debt is the idea that all website 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.
Where Does Technical Debt Come From?
Before a Project is Launched
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 to creating documentation later represents debt. As memories fade, the longer the issue is left, the heavier this burden becomes.
- 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 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’ – 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.
- Parallel development on multiple branches 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”).
- 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.
Strategies for Avoiding Technical Debt
Technical debt is inevitable but there a some measure which can be taken to keep it manageable.
Define the Project
Even if resources to not permit complete, granular specification of a project technical brief, if the purpose of the project is clear, the developer team can make informed judgements to keep the project aligned with the final detination.
Resources rarely exist to foresee every decision that needs to be made in a project. Regular and open communication between developer team and project lead, between project lead and client can help prevent a project drifting off target.