Technical Standards, not Technical Debt
I currently work as the go to person on reliability and infrastructure best practice for a number of teams. My teams are like most development teams I’ve worked for in the past, long on backlog and short on time. I therefore have a big job to get things like disaster recovery and infrastructural maintenance into teams’ sprints. Of course, I spend a lot of time explaining the why of these practices and writing tooling to make implementation as easy as possible (that’s pretty much the point of my job, after all) but at some point I’ve got to get a JIRA ticket on a non-functional requirement into a team’s sprint for their engineers to work on.
One of the things that will normally happen, as I meet with teams to discuss security or deployment improvements, is that I will generally be talking to the engineers and we will be discussing the work in the context of technical debt. In general, all monitoring, disaster recovery, security, deployment tooling, reliability work is considered to be technical debt. I can understand why: it’s a non-functional requirement and there’s generally an existing process for prioritising technical debt, so it’s easy to chuck the work through that process before it gets to the product prioritisation process.
I think it’s a big mistake to treat all work that doesn’t directly happen to the product as technical debt. Everyone is well aware that non-functional requirements are critical to a successful project. However, because they require a deeper understanding of the technical side they are more difficult for a product owner to manage. In the ideal world, the non-functional requirements for the product are prioritised through the backlog in exactly the same way as the functional requirements, with the close communication between engineering and product that that entails. For me, that is a hallmark of a good cross-functional team.
This isn’t the ideal world but it could be (well, fingers crossed!), so I’m working to change the mindset of my teams. Instead of technical debt, I talk about technical standards. For example, rather than incurring technical debt by quickly getting a new feature out, we take pride in maintaining a standard of reliability in a particular product. When we need to iterate rapidly on a new feature, we may temporarily lower our reliability standards in that area. When we’re happy that the feature will be adding long term value, then we work to bring it up to the standards that we expect.
Talking about standards rather than talking about debt encourages engineers to take pride in the standards they maintain, rather than feeling down about the technical debt in their product. It also recognises that high standards doesn’t mean perfect, whereas technical debt carries with it the tantalising but impossible idea of one day being debt free. Technical debt can be hard to prioritise in a feature-focused backlog; changing the focus to the standards the product should maintain helps to clarify which work is most important.
Of course, technical debt is a useful analogy in some software contexts because of its association with interest: that paying back your technical debt regularly avoids a situation where your codebase becomes an unmaintainable blob of spaghetti carbonara. Where I object to it is when it’s being used as a bucket for all non-functional requirements. Having no monitoring on your application isn’t technical debt, it’s being bad at monitoring.
