We’ve all worked on this project: Time and resources are running out, there’s still some key functionality to be delivered, and the Project Manager is making some hard decisions about how to resolve the problems. Sometimes they cut scope, but sometimes they cut back or “postpone” activities for delivery that we can do later “when we have time”… like updating the specifications, finishing up those architectural diagrams, automating those last tests, or refactoring that part that everyone agrees is a pain to maintain (and by extension to test). Congratulations. You have just incurred some Technical Debt.
The sky didn’t fall. The world didn’t end. Everyone is happy because the job got done. Gold stars all round, yes? Except that lurking beneath the depths, rather like the bulk of an iceberg, may be that technical debt. Like any type of debt, the pain is usually felt sometime in the future and spread across time. Sometimes the pain is minor and occurs after a relatively short time frame. Sometimes it is excruciating but isn’t felt until months or years after the decision was made (and the decision makers have long moved on). That’s when you may start to hear conversations that go something like these:
“So there’s no documentation? Well who worked on it last time? Oh…Okay. Well we’ll just have to work around it. Doesn’t anyone have any experience with that module?”
“Didn’t we update those regression tests? No? Why? Oh I see…”
“Well we found the most recent specification for Legacy Application X…but it hasn’t been updated in years. Someone’s going to have to re-analyse the functionality before we can accurately estimate the effort to replace it.”
The further we get from the original decision to defer the pain, ah… the activity in question, the higher the cost may be to do it later. Six months after developing (or testing) that module, the details are no longer easy to recall and it takes a period of familiarisation before the task can proceed. Over time, this tends to increase. More hours. More cost. Less availability to other tasks. Now you’re paying interest on that technical debt. Depending on the task that was deferred that interest rate may, with the benefit of hindsight, turn out to have been sky-high.
While the metaphor of debt is a useful one for describing these issues to someone who may not understand the implications of these decisions, it is less clear how to track and measure it. There is no simple formula we can plug into a spreadsheet. Indeed there seems to be little or no clear consensus on the best ways to track it, measure it or even to determine what the true costs of “paying it back” may be over time.
The difficulty comes from its subjective nature. We might have an estimate of how long it would take to do the task which was accurate enough at the time we recorded the estimate. However as time goes on, the error in that estimate may increase. But by how much and how fast it is difficult to determine. Eventually the task may be overtaken by events when the related function, module or application is replaced and the task may become redundant. But while waiting for this point to arrive, we may have paid many times the original cost of performing the task in working around the fact it was never completed.
Obviously most teams won’t have full control over these decisions. There are many different inputs that weigh into a business’ thinking around these types of issues and the related levels of risk. But we can raise awareness and provide insight into both the potential ramifications of these decisions and the most reasonable timeframes for payback. There are nearly always periods of slower activity, or downtime during the project cycle or between projects. If we track and prioritise our technical debt we will be in the best position, not only to argue our case for payback, but also to make the best use of these limited opportunities when they do arise.
I have seen technical debt tracked in everything from spread sheets to wiki pages, from tagged JIRA tasks to story cards. Whatever method you choose, make sure you make a habit of re-prioritising it. Some types of debt cost a lot more than others in the long term. As with monetary debt, it is all in the interest rate. High interest rate debt should ideally be taken on only on a short term basis. If you do have to take it on be sure to try to prioritise getting it paid down as soon as practicably possible.
I like to use the following rules of thumb when evaluating technical debt:
- How much pain will we incur if this doesn’t get done next month? Now what about in six months? A year? (High Level of Pain = High Interest Rate).
- Are we reliant on a particular contractor or Subject Matter Expert (SME) to do it? Can we reasonably expect they will still be around when we come to do this task? If not, is the area well documented enough that we could manage without them? (High Risk of SME Loss = High Interest Rate).
- Is this task/area complex or poorly designed/executed? Simple tasks/areas won’t be difficult for someone to get back up to speed in, but if it is one of those sections of the software which makes people increase their caffeine intake, seek pain relief and/or a stiff drink it might be a different story. (High Level of Complexity = High Interest Rate).
It is also worth remembering that, as with monetary debt, technical debt is not necessarily a bad thing. There may be strategic reasons for taking it on and even for not paying it off at all. Different projects will have different risk appetites for technical debt. Management on a safety critical system project may have zero tolerance for any technical debt in key areas. Yet the management on another project team developing a commercial off-the-shelf application might take a very different view.
Finally, for most debt there is eventually a point in time at which it should just be written off. If an application is slated for replacement in the near future, the value received from automating the regression suite may be of limited value to the business. In these cases the best business decision may be to take whatever short term pain remains until the application is retired from use.
From a management perspective, the key thing I want is for my teams to be aware of technical debt. I want them to track it, prioritise it, and to understand that postponing a task may come with both costs and risks… and I want my Project Managers to be aware of the same thing.
- Liz Renton, Revolution IT
