5 Ways To Cure Your Tech Debt Crisis
Don't let your environment slowly rot
What is technical debt?
When you think of the word “debt,” you likely think of your credit card. Technical debt and credit card debt are similar; they both let us get something in the immediate term that we can’t currently afford, knowing that it will cost us more in the long run. When it comes to technical debt, though, the currency we’re trading in is time.
There are many reasons why an organization might accrue technical debt:
A decision has been made to compromise how something is built in order to move to the next stage faster, perhaps promising that unit tests will be written later or allowing messy code that’s “good enough for now.”
A system is left to run old or unsupported software and/or hardware to avoid downtime, due to fear that an upgrade process might go wrong or simply to avoid paying for a newer version of software.
A focus on efforts to develop more end-user features and functionality, leaving employees to suffer with manual steps in internal development processes, i.e., a classic case of “doing it manually just this one time.”
And much like personal debt, technical debt isn’t necessarily a bad thing. To ship a product with no tech debt would imply that it was perfect, and perfect is the enemy of good. You've likely encountered software projects that go on and on for years because the organization refuses to ship an “incomplete” project. So long as a conscious decision has been made and there’s a repayment plan in mind, taking on tech debt plays an important part of the lifecycle of a product; in fact, it’s often good to take on tech debt to ship sooner rather than never. What’s key is that you consciously manage that tech debt, just like a company would manage its own financial debts as it invests to grow the business.
Sadly, in my experience, most organizations do a poor job of managing their tech debt. It is all too easy to become swamped by technical debt and become unable to react quickly to market changes because software development has slowed to a crawl.
If it seems like it takes forever to accomplish simple tasks in your business, or if changes that used to take less than an hour are now measured in days or weeks, you’re likely suffering from crushing technical debt.
Technical debt suffocates innovation
In their e-book The Legacy Trap, VMware Tanzu staffers Michael Coté and Marc Zottner describe how organizations can all too easily find themselves deep in technical debt. They describe how, without careful planning, IT architecture can quickly look like “a cross-section of a city’s underground piping and subways, complete with bubble gum and string on water pipes keeping leaks at bay.”
Like a runaway credit card bill, the interest payments quickly negate any positive steps forward. Businesses end up spending the majority of their time supporting their legacy estate, rather than delivering customer value, which, as one executive writes, “is opposite of what I would want to have.”
Any business that is unable to adapt to its market is in material danger.
Why don’t we just fix it?
As we know from our own lives, it’s all too easy to get into trouble with debt if not managed properly. Businesses are no different; it might be that they don’t see the problem until it’s too late, they’re struggling to make repayments, or in the worst cases, the debt has become so large that they feel paralyzed to change.
At its core, the problem is that technical debt is often an abstract concept and its repayment usually offers little overt business value. Unable to draw a direct line between repaying technical debt and increasing revenues, businesses will commonly prioritize new features, unaware of the damage that silently grows in their code base, their software estate, and the darkest corners of their data centers.
Much like brushing your teeth each day, paying down technical debt happens slowly and improvement is cumulative, i.e., you may not see much benefit from brushing your teeth once, but you’ll start to see the harm if you don’t brush for a week, and certainly after a year of neglect.
Organizations that attempt large tech refresh programs often find that a “big fix” approach is fraught with danger, as developers dive deeper and deeper down the rabbit hole of code refactoring and fail to deliver any benefit in a meaningful timeframe. This delay comes from finding more and more hidden problems that need to be addressed. This is analogous to what should have been a simple renovation on an old home. Once you open up the walls or floors, it’s likely that you’ll find problems with the electrical wiring or plumbing, and next thing you know you’re replacing that too or, worse, having to re-level your entire house. And all you wanted to do was install a new shower head to get better water pressure.
When this happens in your software estate, you get bogged down, and both leadership and finance departments lose trust because they are unable to see a clear path forward.
Reduce technical debt slowly and with low risk
Addressing technical debt can seem overwhelming and risky. Instead of paying it down all at once, we’ve found over the years that starting small and slowly addressing technical debt is more successful. The Swift method utilized by VMware Tanzu Labs starts by selecting one application that’s important but not critical to the business, and that is also technically possible to change. This means you’re balancing payoff and risk. And because it’s just one application, you can start quickly and learn. Then you do two more applications, then four more, and so forth. One of the reasons tech debt persists and is hard to solve is because it’s confusing and obtuse, so you need to put a systematic approach in place to discover, experiment, and learn how to fix that debt. Hence, start small, learn, and do more and more.
5 ways to slow accumulation of technical debt
Here are five simple steps you can take today to slow the accrual of technical debt in your estate.
1. Streamline your processes
As any financial advisor would suggest, the first step in managing debt is to take stock of what is owed, as well as the interest that is growing while that debt remains outstanding. You know it feels slower than ever to make even the simplest change to your apps, but why?
Start by organizing a Value Stream Mapping exercise with all the relevant teams to review your end-to-end delivery process and identify where time could be saved. As a group, work out all the steps required between having an idea and delivering value (i.e., implementation in production). It’s important to look both at ways to optimize the process steps themselves, and also the interlinks between stages. A useful tool is to ask attendees to not only give feedback, but also to measure sentiment of each process or interlink. Then find the pain points and tackle those first. You can get a start on all of this with developer toil audits.
2. Automate your testing
As I discussed in a previous article regarding compliance bottlenecks, processes often acquire additional checks and gates to protect against human error. Automated testing can ensure that such problems can be caught early in development, where they are not on the critical path and are relatively cheap to repair. Additionally, it introduces a metric for software quality and can play a vital role in helping to change the culture of a development team, highlighting that how we build quality is valued equally to what new features an application may have. I often ask businesses how often an approval step results in a rejection; if the answer is zero, then it’s a great candidate for removal or automation.
3. Agree on better coding practices
As technical debt builds, software developers are put under increasing pressure to deliver functionality faster, and quality invariably suffers—perhaps the code isn’t very reusable, lacks testing, or simply has defects.
To reduce the number of defects in our code and the time taken to resolve issues when they arise, teams should look at how they can standardize their approach to problems. Pair programming or peer reviews of code before promotion to production is a great way to get developers to work together. There are also a range of tools that help, such as VMware Application Catalog or VMware Tanzu Build Service to build your own curated images or “blueprints,” or giving developers the ability to quickly see what APIs are already available in the organization to reuse with API Portal for VMware Tanzu. The goal is to make it as easy as possible for the team to conform to standards, without referring to long policy documents that gather digital dust on long forgotten SharePoint sites. Internal developer portals (IDPs) are an exciting development that I’m seeing address a lot of these concerns.
4. Plan for the future
If technical debt is the inability to alter an existing system to meet new requirements, then it’s important to consider how we can design and build software for the long term, so that it can be easily adapted in the future. Microservices architecture, where the logical functions of an application are split into their own little applications, has become incredibly popular in recent years. Each of these microservices has a single purpose, making the application more modular and making it easier to change individual functions without touching other parts of the application. This also helps delegate long-term responsibility for an application to a broad pool of teams, who can ensure each microservice is well maintained and remains relevant to the business.
5. Standardize your environment
We’ve seen that cutting corners is a sure way to rack up technical debt. It’s not uncommon for developers or engineers to make small temporary changes to code or an environment while debugging an issue. Unfortunately, experience teaches us that these little shortcuts have a habit of becoming permanent and soon compound as technical debt. You can combat this by standardizing your development environment and using automated tools to rebuild it regularly. Not only does this ensure that no temporary fixes persist, it also instills a better development culture within your team.