When it comes to technical delivery the issue of managing technical debt is becoming increasingly important for digital agencies. Once the preserve of specialist software houses building hugely complex applications; as the nature of the solutions we create have become more complex managing technical debt has become more relevant. Combined this with budgetary and time pressure and it becomes impossible to ignore. However, there is another side to the equation; how we can utilise tech debt as a positive.
Ok, first a definition.
Technical debt, like any other debt; it is a useful tool to pull forward positive outcomes attached to an on-going cost. In a tech context we believe there are 3 broad definitions of debt: 1) delivery of a downgraded solution to meet a number of constraints, 2) delivering a solution that seemed correct at a point in time which however, proved incorrect based on user feedback or performance and 3) a solution which erodes over time due to constant iteration.
What it technical debt is not is: 1) sloppy code, which is unperformant or insecure, 2) code which is poorly documented or architecturally opaque or 3) debt without a defined payback plan. Payback applies as much to code a much as to monetary borrowing. What we’re describing here is a badly written application.
Thereby if we recognise these definitions we can start to understand how we leverage it to our advantage:
Firstly, as an agency we are constantly being challenged to deliver solutions quicker and quicker. Lead time are becoming less and scoping increasingly done on-the-fly. In part this is driven by budgetary constraints; in part because the very nature of the industry we work in has become increasingly fast paced and the desire to continuously drive forward so as not to standstill is constant. In this environment it can be a useful strategy to do things deliberately the “wrong” way if that means we can deliver something on time, on budget. Two caveats here; 1) the implementation needs documenting, tidy enough to refactor at some future date and ideally the repayment (refactor) plan in place.
A second similar but subtly different scenario; where the deliberate introduction of debt can be advantageous is when it allows us the test a prototype more quickly with users rather than wait until the perceived perfect solution is ready. Quite often at the start of development we don’t fully understand the problem. Shipping early and testing our hypothesis in the wild might actually save us time in the long run. The solution we implemented might turn out to be the right one and mitigate the cost of the debt incurred. And isn’t this what we’re talking about when we promote shipping Minimum Viable Products (MVP) that we iterate over based on subsequent learnings?
Finally, we can use it to manage the triple constraints of; budget, scope and time. When in the initial scoping phase of a project it is far too easy to plan around the best-case-scenario. However, in real life you hit a problem you hadn’t envisioned, things go wrong, new features become critical and everyone has under quoted. As we move through the iterative cycle we can introduce technical debt simplifying a particular feature bring a particular constraint back inline. And then the original implement can be deferred for repayment to a later date.
So in conclusion, technical debt doesn’t have to be a dirty word and can actually be used to our advantage. As long as we recognise that tech debt like all borrowing is trade-off. No one would sensibly argue that saving up the entire cost of a house before buying was a good strategy and in the same vain technical debt means we’re borrowing now in order to benefit in the long term. As long as we recognise like all debt it needs repaying at some point.
Paul Barton, Technical Director