Anybody who’s worked in software engineering – be that as an engineer, program manager, designer, or any one of the numerous other roles essential to the delivery of quality software – will be well aware of the term “technical debt”.
At its most simple level, Technical debt is a technical task that was omitted earlier in the project (often to meet a tight deadline) that requires repaying (ie. It still needs to be done). The challenge comes from its nature as a “technical” task – that is, it is most easily attributed to bringing value to the code, or technical team, than it is to the customer.
This tension can often make tech debt tasks hard to prioritise – if you’ve been involved in planning or the management of software engineers how many ties have you heard a complaint to the effect of “I can never get the technical debt prioritised, the business only cares about new features”?
I’ve worked on different teams, on different projects, and at different companies, during which I’ve formed a few opinions on how tech debit is best managed and prioritised, which I think can help teams be most productive.
Before you read any further, I should make clear, that I don’t believe that the “most productive” teams, (that work harmoniously and resolve this tension) manage this by just fixing all of the tech debt. Nor do I think everybody is necessary happy with the outcomes. They key thing is that all parties involved have made a conscious and deliberate decision that they should or should not work on a particular task at a particular time.
There have been several methods used in teams to try and manage this balance – one such technique is reserved time – ring fencing x% of a team’s capacity for tech debt tasks. There are places and times where this works great, but I don’t think it a solution that considers all of the angles.
Andy Bradford 