During my career, I have seen at least a dozen cases where—after several years of consistent development—the code for a piece of software was thrown out entirely, in favour of starting again from scratch.
Why? – because of the ‘Technical Debt’ in that code.
It has always been one of our core development principles to minimise Technical Debt. To most people outside of software development circles that doesn’t tend to mean much. But it is just as important commercially as it is technically.
What is Technical Debt?
It’s the cost of reworking code tomorrow, caused by choosing easier options today.
Software is a lot like an iceberg; what you see above the waterline is only a fraction of the whole thing. While your software might do everything you need it to on the surface, that doesn’t mean Technical Debt isn’t lurking below.
What causes Technical Debt?
It’s usually a combination of factors, common ones are:
- Commercial pressures (i.e. time/budget constraints) on delivery
- Poorly defined requirements
- Insufficient testing / poor testing procedures
- Lack of, or poor, technical leadership
The most frequent cause for SMEs is non-technical personnel (e.g. end-users, business analysts, directors) directly instructing the developers without a CTO or Head of Development in between. Part of a CTO’s role is to bridge the technical and non-technical parts of a business; to translate the requirements from commercial to technical, and manage the development process in a way that minimises Technical Debt.
Does my project have Technical Debt?
Yes.
To a lesser or greater extent, all projects have some Technical Debt because we can’t predict the future, but the goal is to keep it to a minimum.
If your business has developed software, progressively over time, and any of the reasons listed above apply; then it’s likely the project will have growing Technical Debt.
There are symptoms too, but often these can’t be spotted until it’s too late:
- Rising cost of development vs delivered functionality
- Increasing occurrences of the software behaving unexpectedly
- Increasing occurrences of issues and bugs; especially if these are erratic, intermittent and seemingly illogical
- Longer turnaround times for bug fixes and new functionality
- Slower system performance
- Software freezing entirely or crashing
Technical Debt has a compound ‘interest rate’
There is an old English proverb that says “a stitch in time saves nine”. When it comes to Technical Debt, this couldn’t be more accurate.
Software projects only ever grow in size, and the more development that takes place, the more the effect of Technical Debt is multiplied. So pushing ahead with development, without taking the time to deal with that debt first, will only create more and more Technical Debt.
And that’s why I’ve seen so many projects throw out their code in favour of starting again; because the cost of repaying the Technical Debt exceeded the cost of redoing several years work.
How can it be cheaper to start again?
Most businesses don’t have a clear picture of what they’ll need in 3 or 5 years’ time, so the software is built progressively. There are widely used methodologies for approaching development in this way, such as Agile or Scrum. But, while they allow the software to be developed in line with the business’ needs at that time, they also result in repetition, backwards steps and building features that are subsequently retired.
Also, a lot of the costs associated with development are not directly from writing code. Project management, capturing requirements and user-testing are a consistent and repeated part of the process too.
However, when starting again, you have a clear picture of what the business needs, the requirements are well known, the project management is minimal, and repetition non-existent, so the majority of effort goes directly into writing code. Therefore, the process is much more efficient, meaning something that took 3 or 4 years to build the first time, can often be ‘re-coded’ in 6 months or less.
Is Technical Debt always a bad idea?
No, sometimes incurring Technical Debt can be a sensible commercial approach. If doing so gets your business new features or functionality ahead of your competition, or in a way that the benefits outweigh the costs, then it’s positive. But the business should be aware and deliberate in pursuing that strategy.
It’s also appropriate when building a proof of concept, or minimum viable product. In these scenarios, it’s unlikely the end product will be built from these foundations. So the Technical Debt will never need to be repaid.
But, continually developing in a way that incurs Technical Debt will, inevitably, end in disaster.
What can I do about it?
If you’ve already embarked on a project that has built up Technical Debt, I’m sorry to say there is no silver bullet. But whether it’s a new project or continued development on an existing one, the most effective way to counter the trends which result in Technical Debt is the same:
Strong and experienced technical leadership.
The expense of a good CTO might be painful at the start, but they will save you a fortune in the long run. They will do this by implementing procedures and processes around development, things like code style and structure guidelines, and ensure sufficient resource is allocated to reducing Technical Debt as a project progresses.
Plus, they might help you save in other areas. In my experience, you will get a better outcome with a team of less-experienced developers but strong leadership, than a team of more-experienced developers with weak leadership.
And this leadership doesn’t have to be in-house. Working with a 3rd party development company will be fine, so long as they have that technical leadership in place.
If you’d like to know more about how we can help your business, we’d be delighted to talk to you.
More insights
Get in touch to discover how your business can thrive with our Digital Transformation as a Service.