I’ll start with an explanation of technical debt, although its an accepted term, it’s still not a widely known concept. Knowing what technical debt is, what causes it and how it impacts an organisation is moving towards being a critical-mass issue.
Technical debt is the overhead or cost associated with working on a project that is having to refactor or redesign code that was previously deployed and is less than efficient. That efficiency may be driven by its lack of documentation, maintainability, missing comments, unusual styles or just a simple hack. Technical debt typically arises due to project pressures based around schedule, budget or a ‘just get it done’ attitude. Code, to use a known term, is ‘slammed together’ to get it working and then the team move on to other things. This less than perfect implementation leaves a future debt where a following project must work with this legacy and carry the costs associated with its deployment. Hence the term technical debt.
I’m a former developer I can unfortunately confirm, as can most, that we’ve been guilty of getting the code out of the door when requested often foregoing tidiness, documentation, comments, etc due to other pressures. As a Project Manager I’ve also been guilty of driving such behaviours and leaving behind such debt due to those schedule or budget pressures and even at times, management telling me to get the job done and ignore such needs.
That debt accumulates over time and grows like a cancerous lump that eventually gets to a point where its impact becomes impossible to manage. Working in financial services I see this all the time. Legacy systems that do something, we don’t really understand what or how any more and the idea of replacing such systems becomes an impossible task and so we keep them at the core of our infrastructure for fear of breaking something.
2019 has seen a rapid growth in fintech challengers such as Mint, Monzo, Stripe, Avant, the list goes on who are stepping boldly into the arena and offering a direct challenge to the established institutions. Those from the outside, and many from the inside, often ask ‘why aren’t the banks reacting in such an agile manner?’ The answer is driven in part of course by too many tick-box processes but also to a much larger part by their technical debt. Years of restricted budgets, offshoring of development projects and tight timelines has done nothing but drive that debt deeper. Deeper to the extent that understanding these systems is now akin to trying to climb out of a coal min wearing ballet shoes.
For a lot of institutions there’s a dilemma behind the core operating model if they are going to challenge the new upstarts. Do they invest in fixing the technical debt or do they start again?
I’m not convinced that the industry has enough focus on the issues behind technical debt and the legacy issues that it’s left behind but I feel I can answer the question posed in this articles headline, who’s to blame. The answer is everyone. The developers for short-cutting and not documenting or commenting, the project team for underestimating the efforts including refactoring, the project managers for not pushing back on behalf of the team and the organisation itself for applying such pressures.
Until we stand still for five minutes and assess the size of that debt, we’re not going to either mitigate or resolve the issue and until we do, the old-guard will continue to see the upstarts not only challenge but eat into their market share. This is, in essence, no longer an IT issue, but a bigger and wider business challenge, it’s time to wake up to it.
About the Author – Rachael Evans is a Project and Program Management Consultant who has over 20 years of delivery experience working with Microsoft, Vodafone, Credit Suisse, HSBC and others. She has worked in Switzerland, the UK, Ireland, The USA, and India and has delivered over 200 Million in project investment. She has taught project management for over 15 years in both group and one-to-one settings. Rachael is a fellow of the Chartered Management Institute, she holds a Business Management Research Masters and is a published business author.