This last year has been all about change. And if your company has embraced the opportunities change affords then you’ll have probably brought forward strategies to move to the cloud and develop and use applications to facilitate all sort of contactless transactions.
This abundance of business and digital transformation projects has shone a large light on the extent to which companies have been reliant on legacy systems that haven’t moved with the times and the notion of technical debt is now more prevalent than ever. In short, if you need to replace or update legacy systems to deliver the strategy then you’ll no doubt be under a huge amount of pressure to get it done fast to win new customers or lower costs. That leads to cut corners and creates an entirely new problem in itself.
What is technical debt? It’s easier to explain it using an example.
Imagine a developer is coding a new customer facing feature into an existing platform. As is often the case, there’s a time constraint and the work has to be completed quickly so that a new customer feature can go live ahead of the competition.
To meet the deadline the developer cuts a few corners. Nothing drastic, nothing that would be visible to the user, but a few small things that get the project delivered on time. Perhaps the data access isn’t as efficient as it could be, maybe there’s not much in the way of test coverage, and there could be a few ‘magic numbers’ in the code that move processes along.
At first, this approach won’t make a material difference to performance and the customer experience. But over time these little shortcuts build up, until they stand in the way of progress.
In practical terms it means that because the data access is inefficient, the applications will run more slowly when it’s scaled, making it harder to add new features with acceptable execution times. Furthermore, the lack of test coverage means new features spend longer in quality assurance and those magic numbers add days to solution design, while someone figures out what they mean and if the new functionality needs them to change.
All of this usually becomes apparent at the point there’s a requirement to make changes quickly to meet a new strategic deadline, or customer complaints start to go up. The upshot is you are once again looking for ways to cut corners on a system that is already suffering from having its corners cut.
It’s easy to see how things can grind to a halt.
So how can we prevent technical debt from having such a huge negative impact?
There are a few things worth thinking about:
- Designing for modification
- measuring debt
- creating of a ‘technical debt register’
- appreciating not all debt is bad.
- Designing for modification
Most software is, at least in part, obsolete at the point of delivery. It’s seems ridiculous but it’s a given of software development – while the application is being built things changed, new requirements emerged.
It’s therefore important to realise that at the point of design there’s always something that could or should be done to the system, even on it’s go live day.
At every opportunity ask how easy it would be to add features or change rules. Create project specific coding standards that explain how to make changes and include in them expected timescales for making these changes.
This provides some protection from downward time pressure. The proper use of Object Oriented Programming techniques can be a lifesaver here – just as the improper use of them can lead to disaster.
Designing for modification is one of the most important aspects of system design. It’s right up there with User-Centric Design, Design for Scale and Defensive Programming. It’s also the most commonly overlooked. If you are lucky enough to be starting from scratch then consider this – a platform is for life, not just for Christmas.
- Measuring debt
You can recover technical debt by looking at ways to measure it. For example, knowing how many bugs there are and formulating a plan to fix them will have an impact on the maintenance and improvements done in future. It’s a way to keep a track on things that are contributing to the debt and do something about them in a systematic way.
That requires some prioritisation, as you don’t want measuring debt to become all-consuming to the extent that you lose sight of the purpose and overall performance. Perfection isn’t what this is about. It’s about progress and remedying the things that would hinder progress in future.
At VDP we use two measurements that reflect the support hours the product would consume, referred to as Kanban workflow, or if the system is still in development, we use Scrum workflow or ‘Agile Points’.
- Creating of a ‘technical debt register’
This is a technique we’ve found very useful both for clients whose systems were riddled with debt and also those starting afresh. The register tracks each individual piece of non-ideal coding and puts a time value against it i.e. how long it would take to fix. Then when that piece of debt causes an issue for further development the additional work is tracked as ‘interest’ on that debt.
The interest will keep growing until you pay off the principal figure, and you will be able to see what effort will be required to pay that extra debt off. This can be a very useful planning tool and can highlight the point at which paying down the principal debt would actually be cheaper than continuing to cut corners.
Technical Debt Registers are easy to create if you start when you’re first building the system. Creating them for existing systems is harder and as a rule of thumb you should allow a full sprint to create it.
Given that high technical debt is often a symptom of time constrained development it can be difficult to convince people that it’s worthwhile to use a sprint to record the things that are wrong and estimate the time to remedy them. However, it’s pretty fundamental to have this if you want to avoid diminishing returns and platform rebuilds.
- Appreciating not all debt is bad but is unavoidable
The final thing worth bearing in mind is that technical debt is unavoidable. It’s not a symptom of bad development, it’s an inevitable consequence of changing requirements and business needs. All systems carry some.
If you have a register you can decide what level of debt suits your needs and business outcomes. If customer experience will suffer and it will have a detrimental impact on revenue then it’s worth investing in a fix.
There are of course things you may decide never to fix as the ‘interest’ on them is low and if you were fortunate enough to be able to ‘Design for Modification’ at the start of the process then most of your debt should be low interest anyway. If it’s not, there are ways to tackle it so business transformation can continue. But it’s imperative to get a handle on it sooner rather than later.
Bottom line is, technical debt won’t kill you or your customer experience, unless you ignore it.
If this all rings true for you and you need help getting things under control and/or want to start and deliver new projects without incurring high volumes of debt then speak to us.