Tackling Tech Debt with Managed and Professional Services
You rushed through a development job. Or failed to thoroughly test and document. Or put on a bandage where a replacement was in order. Maybe your system lacks full composability, so a new function rendered others incompatible. Maybe you only had the staff or skills to do part of the job, or you didn’t realize the job was only half done. Now, you have acquired tech debt.
Tech debt—or technical debt, or code debt—is what you owe when, for any number of reasons, you defer the completion of a development job to a later date. You “owe” your system a new app, function, or subroutine, a revision of a rapidly released app, or other work to fulfill the needs created by an earlier, completed job. In the short term, and in cases where it’s part of a well-planned strategy to get a release out quickly, tech debt doesn’t necessarily constitute a problem. Most people acquire similar financial debt: we make car and mortgage payments so that we might have homes and cars without saving up the full cash price first, and when we plan well, those payments fit within our regular monthly budgets. But in other cases, tech debt behaves more like credit card debt, compounding with interest as time passes and adding up quickly as deferred tasks multiply. What started as a well-intended effort to make a small-scale change is now a twelve-car pileup of coding to-do lists, functional gaps, and never-ending patches to keep insufficiently developed software running. How big is this pile-up? In a 2020 McKinsey survey, CIOs reported estimating that tech debt accounted for 20-40% of the value of their technology estate.
So. What now?
The best way to address the more problematic aspects of technical debt would have been to prevent them with a solid DevOps approach at the outset. But the time machine is crashed somewhere in that twelve-car pileup, so we start where we are: with tow trucks and emergency vehicles and road cleanup crews, and then with strategic measures to make sure tech ledgers remain manageable, if not clear. Let’s say, for comparison’s sake, that the emergency vehicles and road cleanup crews in this metaphor are manned by pro-serve staff augmentation or an expanded and upskilled in-house staff, focusing on remediation of piles of bugs and deferred code fixes. To get and keep tech debt under control, you’ll also probably want some help with refactoring monolithic legacy code into composable microservices for agility and flexibility in future development.
But for the long haul, to manage tech debt and prevent the wrong kind from accumulating, you might require a digital transformation, during which your organization can implement best practices like DevOps, automated testing, CI/CD processes, and developing architecture alongside new feature development to ensure that both aspects are regularly addressed. In isolation, these practices may not seem like profound alterations in the landscape, but in that isolation, they are unlikely to manage and solve recurring tech debt. In tandem, they represent a substantial cultural shift in any organization that employs traditional development processes. For many organizations, partnering with a managed services company is essential to effecting and maintaining such enormous cultural change.
Tech debt has real cost. When it goes unaddressed, it impacts customer experience directly, and the related costs in staff time and development delays are tremendous. It remains easy to ignore, until its impact makes itself felt in an organization’s bottom line. Preventing that impact requires a hard look at the current circumstances (Are we headed for a crash?) and at best and worst case scenarios (What would instigate such a crash? Which of our vehicles will end up in the pileup and which can cruise by on the shoulder?) followed by an honest conversation about priorities, and a commitment to mitigating imminently threatening tech debt and engaging the tools and services necessary to keep it in check.