Hands up who didn't see this one coming?
Technical debt is one of those strangely taboo subjects in the development world. Everybody has it, but nobody wants to talk about it when it comes to sprint retrospective time. Which is strange, as one of the first things any group of developers talks about down the pub is the amount of tech debt they're dealing with, what tech debt they were forced to create by not owning architectureor requirements, and who's getting the next round in.
At a simplistic level, there are three main resources concerned with getting a project done:
- Time in
- Money in
- Technical debt out
Generally if you want something done fast you can either hire more and better developers (with diminishing returns) or accept the creation of more technical debt during the project (again, with diminishing returns). The best companies, or at least those with a finite budget, operate with a careful balance of all three.
That's an important point I try to get my teams to understand. You're not inherently being a bad developer by creating technical debt, as long as it was done with good faith in the interests of getting things done.
What separates the good from the bad is how you deal with that technical debt. The best teams can say upfront what technical debt they're likely to create and factor it into their planning, being able to present alternative burn-downs and release dates based on how much is created. Even without that, good teams document the technical debt they've had to compromise on to give an honest and accurate view on what needs to be dealt with in the future.
The key is that a team which is honest about the technical debt it creates is able to then look at that technical debt and address it in future projects. You get early warning of when it's building up, and a good picture of which projects need attention before they turn into an unsustainable mess.
How you go about addressing that technical debt is a question in itself, and one I'll answer in a future post, but I wanted to start with a important point about technical debt and ownership in general: the starting point is to be honest and open. Technical debt: every development organisation has it; what differentiates them is how they deal with the problem.