Technical Debt is a term that refers to the concept in software engineering (and hence web development and app development) that taking shortcuts early on in the development process can prove to be a false economy and that a better approach (that might take longer and be more expensive) could result in less costly rework in the future.
By referring to the concept as “debt”, technical debt implies that there is a monetary value owed to the project. Interest accumulates on an unpaid debt, and when unaddressed it can lead to technical entropy or software rot – effectively the slow deterioration of the platform and the increase in the number of issues it experiences.
The phrase is by no means a new one. Ward Cunningham first used the term as early as 1992. But its understanding is still mainly limited to technical audiences, and it is rare to encounter a client who is aware of its implications.
To the casual observer, this might seem like an old wives’ tale that’s promoted by contract software developers to increase the upfront project value. The same clients would likely also struggle to justify the value in paying for the writing of automated tests or investing in a fully scoped technical specification prior to development starting.
As web and app developers, the need to consider the long term implications of buying cheap can be one of the hardest conversations we need to have with clients or partners, but when addressed properly it invariably leads to the best results for projects.
Part of the issue arises in the fact that websites were traditionally built by design or marketing agencies who generally sold the projects as one-offs. Little consideration was given to the longevity of the solution or the maintenance after its launch. This mindset infiltrated the typical web or app brief and budgeting process. Web developers tended to be the furthest away from the sales process (especially due to the number of outsourced/overseas development teams), meaning that their feedback or suggestions were less likely to make it into refining the commercial team’s discussions.
Developers (especially those of us who are lucky enough to be in UK based, onshore teams) have gradually found their voices and are starting to clamour for better processes. Technical debt is an issue that encompasses many such recommendations.
The truth of the matter is that even the best-planned, well funded and conscientious development teams will incur technical debt. Opting for a different supplier won’t avoid this, but they might just be less upfront about the issue.
Technical debt is built up of “cruft” – any deficiencies which make it harder than it should be to update and maintain. These could be caused by:
Our aim is to produce as little cruft (and hence technical debt) as possible due to bad development practices. As a specialist team, we wouldn’t survive long if we incurred significant issues here, but no skillset is perfect and even experts have to account for this.
Where we aim to help clients and partners is in ensuring that they understand that investing in testing and documentation is a long term investment that they should consider if they envisage a long lifetime for the project. Marketing websites sometimes only last a few years and it is harder to justify here, but with product and platform development, this should be given greater priority.
Last-minute changes in specification and the need to meet deadlines is an unavoidable fact of business, but we’ll ensure that the budgetary impact of doing so is always communicated in a change control – including the refactoring that may need to come later on.
Martin Fowler introduced the concept of the Technical Debt Quadrant back in 2009, which identified that there are four types of technical debt:
Whilst this quadrant helped to explain that there are legitimate reasons for technical debt, even amongst able developers, it did highlight that the debt metaphor doesn’t always work particularly well (it’s hard to imagine an inadvertent but prudent financial debt) – which just goes to reinforce that the concept is not always going to have a direct analogy to make technical debt palatable to management.
It’s part of our job as professional developers, to ensure that the majority of technical debt is incurred through deliberate decisions and that the potential impact of these should be communicated to the client when it is made.
The best practice convention is that a developer should always leave their code better than they found it. This means that when a developer happens upon or incurs known technical debt it should be classified and a plan should be put in place for its refactoring at a later date.
We now always discuss the ongoing maintenance of a project with a client, as well as its likely cost, in the very early stages of negotiations. It’s always better to be upfront, and clients who haven’t been through the process before shouldn’t be kept in the dark about the fact that the initial investment in a website or app is just the downpayment in its refinement over its lifetime.
If you think your web and software projects have been let down by technical debt in the past, then get in touch below to find out how we would advise managing this in the future.
Purr uses cookies
We use cookies to provide you with the best experience and improve our site. You can find out more in our Privacy Policy