I want to expand on something from a previous blog post that generated a lot of interest: “debt tickets”

Debt tickets are a way for engineers and product owners/business stakeholders to handle a common issue that comes up between the groups. Engineers love test driven development for good reason, but there’s no denying that in the short term, TDD takes longer than non-TDD. Product owners love having features go out. Obviously these are very broad statements, but they’re basically correct.

The issue I’m talking about usually comes up during crunch times, but can show up even in daily work. It’s where engineers want to do things right, and a business stakeholder is pushing to just “get it done”. One of my favorite things about this strategy is that it can be brought in by the engineers or the product owners, and it’s win-win for both groups.

The strategy of using debt tickets is, admittedly, really simple. Sometimes corners need to be cut to hit deadlines, there’s no way around this idea. The problem with cutting corners in software is that over time, it leads to massive amounts of technical debt that can cripple a codebase, and an organization.

The next time a corner needs to be cut for speed/deadline reasons, go ahead and cut that corner – but add a ticket to the backlog that has a note about what was done, what part of the codebase it’s in, and what else remains to properly complete the feature. That’s a debt ticket – it documents the existence of technical debt, and serves as a reminder for where the code can be cleaned up in the future.

This is a good strategy that can be started by the engineering team, and also provides accountability to the business stakeholders. Not everyone outside the engineering organization can understand saying “the technical debt is really building up”. It’s much more effective to say “we have these 20 features that were originally experiments but never got properly integrated”. This also helps the product team because there may be times where they need to temporarily surge on the speed of development.. This method provides a written record of technical debt so that it can be revisited after the surge is over.

For product folks, this strategy is best if they get pushback from engineers if they need to surge development. If an engineer is saying “no, this has to be tested”, debt tickets can be used as a win-win negotiating strategy.

"Hey, look, I know you want to do this with TDD, and I like the fact that you do high quality work. The thing is, right now we have to get An Awesome Feature out the door because of the deadline. What if we put a separate ticket in the backlog for 'refactoring An Awesome Feature', and we'll work on it in the first sprint after the deadline?"

You can also take this strategy outside the surge context and use it for managing technical debt in general. When engineers run across things they’d like to clean up, they should always be encouraged to add a ticket for the issue and put an estimate on it. This provides a way for business stakeholders to ‘see’ the technical debt that exists in a code base. Even though technical debt isn’t ‘real’ to them in the same way that it is to an engineer, tickets are. They’re real and can be seen and counted, and it keeps everyone on the same page during discussions.