We need to talk about tech debt
Technical debt is part of the landscape of development. But so often it's the elephant in the room - we all know it's there, but we can't talk to customers about it. Why is that?
What is technical debt?
Technical debt, or tech debt, is the term used in (software) development for the mess you store up for yourself when you do something the quick way, not the right way. The metaphor is a catch-all term for the consequences of all the shortcuts and poor decisions driven by timeframes, or budgets, or the desire to ‘just get it done’. By taking the easy route now, you pay for it later (with interest).
The repayment takes the form of the extra time you spend in maintaining a sub-standard codebase. A system that’s less stable. More time spent bug-fixing. More time to develop new features because you have to work around those short-cuts. Refactoring and unpicking bad decisions made weeks or even months ago.
Technical debt hits dev teams where it hurts in terms of productivity, and it also takes its toll on morale. You can feel it in the lack of the pride in the original work, in the knowledge of shipping something not entirely optimal. And you can feel it in the slog of refactoring something, the frustration of wading through bad code, and the drag on timescales when it’s payback time.
Can’t we just do it right the first time?
Some amount of technical debt is unavoidable. In any walk of life, looking back at most tasks we’ve carried out - we can often see how we might have done it better, or more efficiently. Sometimes you can let that slide, but other times – like when you come to build a new feature that rests on your original efforts – you have to do a bit of a re-think.
Hindsight aside, almost all other times tech debt is incurred, it’s down to project pressures – time or cost. Nobody ever commissioned a website or a piece of software and said “just take your time and let us know when it’s done” – there are milestones and deadlines to be adhered to. Similarly, in development world (where time spent and cost of product go in lockstep), every task must be allocated a time so that it can be given a cost. So when a developer reaches the point where there are two choices, the quick way or the right way, very often the project timelines and budgets are set against him.
Bringing tech debt out of the closet
Which brings me to my question: why isn’t technical debt more often part of the project management dialogue?
In general, we tend to treat the idea of tech debt as an internal matter. Customers are not interested in the ‘how’ (the theory goes) they tend want to know about the ‘when’ and the ‘how much’. They don’t need the detail about the best way to do something, and whether that fits into the timeframes, or whether there’s a quicker way and what the consequences of such a decision might be.
As a project manager, sitting between the development team and the customer, I’ve struggled to discuss tech debt with customers in a way that makes sense to them. I once saw a measurement of technical debt described thus: “what percentage of a team's time is spent doing work that can't be explained in a way that the customer is happy to pay for”. Which for me, hits the nail on the head. Both avoiding and repaying technical debt can add unexpected hours into the project – and (although the former is definitely the way to go) I struggle to explain either in terms that I’d be comfortable with, if I were a customer.
We had an example just recently. A new feature was requested, and we could do it the ‘quick’ way, or we could do it the ‘right’ way, which would take nearly twice as long. The quick way gets it done. It works for the end-user. It sits at a cost-point I could reasonably expect the customer to agree to. And - critically - it doesn’t have any demonstrable drawbacks. It’s all good. Except that the team don’t like it, because it has a high risk of incurring technical debt.
And I get it. But there's no demonstrable drawbacks, remember? So how do I go to the customer with that? Do I only quote the ‘right’ solution? Or do I – in the interests of honesty and transparency - allow them to choose, knowing that because I have no good way to illustrate the difference, they will choose the cheaper option. Because, who wouldn’t?
So what’s the answer?
There’s no magic answer here, of course. Businesses have been wrestling with this for decades. Despite having a strong metaphor to use, explaining why something takes longer and costs more is still a difficult conversation to have with clients.
But it seems like we’re doing nobody any favours by ‘shielding’ customers and stakeholders from these issues. In an environment where there’s multiple ways to achieve the same end, we invest a lot of time and effort into working out what’s best, both for getting the job done now and – critically - to avoid storing up trouble for later. So, even if it’s not the easiest conversation, I should be able to communicate that to our customers.