Strive for real-world technical debt management in DevOps orgs
Technical debt is a bit like the kitchen junk drawer: It's cobbled-together, useful stuff that just needed to go somewhere. But the longer you wait to sort it out, the worse it gets.
Technical debt -- two words that no DevOps engineer wants to hear. Technical debt is the skeleton in the closet of high-performing IT organizations. Everyone has it, no one wants to admit it and few understand appropriate technical debt management techniques.
The fear stems from the connection between Technical debt and poor decisions on the journey to get to a finished product or automation workflow.
Technical debt is the implied cost of an easy fix rather than the best fix. It is a tradeoff of fast task completion today with additional rework required at some future point. You get through the immediate issue, but at what penalty?
In the real world of IT, the more accurate way to define technical debt is that it occurs when a perfectionist engineer goes against his very being to put hacks in code just to satisfy a manager who is under pressure from the business to ship this product yesterday.
Long a bugaboo haunting software developers, technical debt is increasingly important to IT infrastructure and DevOps teams that manage configurations and deployment processes with code. Site reliability engineers, also called infrastructure developers, implement changes programmatically, rather than ad hoc, to manage and optimize application deployments at scale.
Technical debt accrues over time under mounting pressure to deliver. Engineers get tired, and design considerations are deprioritized. Everyone starts a project with blissful glee, confident that they'll do everything right, but as Mike Tyson famously said: "Everyone has a plan until they get punched in the mouth." Deadlines are that punch to the face, and technical debt is the increased risk of brain damage over time.
Without appropriate technical debt management, problems can spiral out of control. More shims and hacks must happen just to stop the hemorrhaging that the other hacks created. Before long, the only way out is a complete rewrite -- a task few IT organizations can accommodate.
Technical debt doesn't have to be thought of as a wart on your organization. Instead, teams can adopt a style of technical debt management that accepts it for what it is: an effect of an earlier, less-than-optimal design decision to ship a product. That's it.
Everyone has external pressures to deliver, and no one can provide a perfect product out of the gate. That technical debt is merely the cost of producing value for customers sooner rather than later. To operate without any technical debt, the team would still be in meeting after meeting to discuss how to avoid a two-part process to spin up the right OS version on a VM, since, theoretically, it could be done in one.
Technical debt positives
Technical debt isn't inherently good, but it can lead to conversations around better ways to deliver software, increase automation and implement better processes.
In the DevOps world, technical debt is a necessity. DevOps aims to deliver value to the business as soon as possible. It doesn't have to be perfect; it just has to work. DevOps organizations accept some tradeoffs. Organizations are more tolerant of failure and iterate on tasks much more quickly with a realistic take on technical debt management. Speed is in the nature of DevOps, and zero technical debt is a pipe(line) dream. DevOps organizations realize that, if nothing breaks, the value stream is drying up. Move fast and break things, as Facebook's unofficial operations motto once directed.
Technical debt that results from high-speed, flexible DevOps approaches shouldn't be hidden shamefully. It should be treated like a battle scar on hardened DevOps veterans. Technical debt isn't inherently good, but inherently good technical debt management leads to conversations around better ways to deliver software, increase automation and improve processes.
Follow these technical debt management guidelines to navigate between speed and perfection.
Technical debt management dos
These steps should encourage rapid innovation and effective collaboration, without letting technical debt spiral out of control.
Make everyone on the team document the decisions that add to an instance of technical debt.
Have regular checkups on the effects of technical debt-laden design decisions to measure their impact.
Routinely come back to existing code, and reduce technical debt when time allows.
Develop a culture of transparency. Transparency is part of the communication and trust that make DevOps work.
Technical debt management don'ts
Many IT teams develop negative habits in both tasks and culture when it comes to technical debt. Follow this advice to work better and smarter.
Don't shame anyone for adding to a technical debt.
Resist the urge to prioritize other pressing work over technical debt. It will catch up to you eventually.
Never hide from technical debt. Treat it as an expected cost of doing business.
It takes some willpower to focus on technical debt and not work on the latest, shiny feature on the horizon. Keep technical debt management at the forefront of development and IT automation efforts -- not relegated to the catacombs of the backlog, never to be seen again.
Dig Deeper on Systems automation and orchestration
