We can spend an incredible amount of time on the topic of financial debt and how to manage it correctly or even better yet, avoid it entirely. Not just from a personal perspective, but corporate perspective as well, with many companies relying on debt to survive. Today, I want to talk about another form of debt that doesn’t get spoken about as much, but remains equally, if not even more important in their pursuit of technological advancement. That of technical debt.
Technical debt accrues when we focus on driving our main business objectives rather than dealing with a variety of software and IT related tasks and updates that might bring systems and software development processes more up-to-date. While this is completely understandable and seems like the right approach for many businesses, it’s often a very slippery slope in the software development world where if not managed, can lead to long term stagnation in software development output.
Technical debt basically represents a backlog of work that needs to still be done by your team, of any nature. The challenge is that with development teams continuously focusing on forward looking development and delivering value to the business, these tasks seldom get prioritized and backlogs just end up growing. The big problem with this though is that often these tasks are more important than you realise and what seems like a low priority item in terms of business value now, is often a big inhibitor of delivery much later.
Take test automation for instance. Teams scramble to get everything automated, but often don’t and would rather close out the story to deliver the functionality to the business and appear more productive than do what they should and not close the story until the automation work is complete. Test automation though is not just relevant to the story at hand, but relevant to any future regression work done for that particular piece of functionality, so all you actually end up doing is slowing down your development process.
Same goes for putting in the effort to build features that enhances your ability to deliver faster, like CI tooling or better, more comprehensive environments. They too often get marginalised and deprioritized because they don’t deliver actual value and the business would rather the time be spent elsewhere, but failing to make these technological changes a main priority in your development work means that you are unlikely to catch it up in the future and slowing down your overall development work.
Essentially thing that should never land up in your tech debt backlog are:
Automation
CI tasks/tooling
Security vulnerabilities
Tool Updates/Enhancements
Major Defect Fixes
However, I do understand that you can’t do everything and certain things will always fall by the wayside. So, what do you deprioritise then and allow to form part of your technical debt? Well, if you must, then rather let it be your less important features that get descoped than your technological drivers. One of the reasons why I say this is functionality can always get caught up, but often your technology drivers need to be implemented soon to capitalise on the benefits they bring and while you may think it will slow you down now, you need to be thinking about the long term development of your software as well. It sounds bad, but deadlines for functionality are not everything if the underlying architecture of the software and its test automation is going to cause future pain.
As with everything, there are always caveats to the rule, especially for legacy systems where running with the latest technology is not always necessary or architecture is getting phased out. However as much as possible, look at ways of curbing your technical debt and rather say no to taking on more functionality than pushing out the extra development steps that you need most.
Say no to technical debt and much like your financial self, you will feel more free and able to invest in your product roadmap for the future.
Comments