What is technical debt and how best to manage it

If you are leader in business, you will no doubt have some responsibility for ensuring your company has software capability and that any associated products are delivered in a timely manner. However, with speed comes cost – either, higher fees or fewer functions. I’ve previously written on the cheap, fast and good triangle in development and that with speed comes debt.

With faster deliverables and tight timeframes, less ‘necessary’ work goes onto the backlog. In short, it’s the things that fall off the priority list to be put on the ‘to complete at a later date’ list.

This often occurs because the time frame for completing a software project is too unrealistic or short for the work that’s involved. In this instance, only those tasks that can be completed with accuracy will find their way to the end product. This sounds worse than it is as it’s a reasonable approach if there is a large workload as your development team will be keen to give you something to play with and roll out.

The downside is that the backlog list could continue to grow if there’s pressure to keep delivering new functionality when the old list is becoming unwieldy.

What happens to software that has a lot of debt?

It may end up with holes. It won’t be the efficient machine you had been promised and it can begin to feel chaotic and far from unfinished. We accept that a development will constantly evolve once the core of it is in place and that is a very good thing because it shows that your users are fully engaged and happy with the overriding performance. However, the difference with this result and debt is that the software could begin to crumble. Worse case scenario is that it never gets released into the real-world domain. It then starts to fail on its promised value.

There are warning signs so here’s what to listen out for

1. Testing only for the short term to get it over the line. No pressure testing of the entire system
2. Only developing with the task in mind, not with foresight of future requirements
3. Hacks and workarounds to get a feature shoe-horned in against best advice
4. Putting good practice on hold and on the list
5. Older code from older devs who rely on historical methods when time is short
6. Badly written code – it happens under pressure but that’s why you have senior engineers who have a stake in the business
7. These issues are more pertinent to bespoke builds but the same debt can be found in company enterprise systems where the relationship is through a licence.

Off-the-shelf products cause an almost impossible route to innovation or growth of the product inline with their business goals. Businesses end up living with systems that are no longer adding value and only serve to stifle them.

What should you do to tackle it?

1. Look at your support team: do you have the right people in place to keep the project tight and with a constant eye on the value it’s delivering? Your team should consist of senior architects, developers, business analysts, QA testers and project management.
2. Use some meeting time as a focus on technical debt so that it becomes more prominent in everyone’s mind but is not there as a punitive measure for everyone who is working really hard to deliver.
3. Be as realistic about the outcomes as possible. If you think loading up the timetable will happen without any trade-off, think again.
4. Plan your project in mini projects. Treat legacy code as a project in itself, the same with deployment and this will give you more achievable timeframes.
5. Encourage transparency. Constant communication about any elements that are falling behind or proving complex should be addressed and not ignored. ‘Leaving to later’ is simply code for debt.
6. Lastly, don’t be afraid of a little debt. A bit like a credit card it can be handy, but pay it off quickly before the interest kicks in.

Your project won’t avoid technical debt but it can be managed effectively by a good team who are aware of its presence and the common ways of acquiring it. Making it a part of the project rather than something to hide from will keep your development successful, on time and with aligned values.