Getting Unstuck From Technical Debt
You’re stuck. Your software is outdated well beyond the point of just being an eyesore and your business is really feeling the tug against any forward momentum. It’s an anchor around your neck. You’ve tried but you can’t just fix it and you’ve looked into it but you can’t replace it. You depend on this software so you can’t just scrap it, even though you’ve thought about just going back to the stone age of spreadsheets and email – paper forms even. The feeling of just being stuck is starting to feel overwhelming. So you’re left with figuring out how to keep it running as best you can. But how long do you need to keep it going? How much should you try to fix it?
Sound familiar?
These questions can feel unanswerable and there’s a real temptation to just do nothing and wait for it all to come crashing down. But as always, large problems are easier to solve when broken down into smaller parts and doing something is better than doing nothing.
Let’s look at the difficulties you are facing in a more granular way. In what ways are you feeling stuck?
Unstable
- Are fires common? Does your IT team feel like they’re always “on-call”?
- Do you constantly need to reboot servers, clear storage, etc?
- Is there a constant influx of bad data that needs to be fixed?
Buggy
- Is there a lack of trust that the system is working correctly?
- Do you have a long list of bug reports that you can’t even recreate let alone fix?
- Is your list of workarounds longer than the list of features?
Ugly/Unusable
- Are you self-conscious that customers notice your application is aged?
- Are users having a hard time figuring out how to use the system?
- Does the interface lack basic functionality like mobile optimization or responsiveness?
Brittle and Insecure
- Does any attempt to make changes (whether it is to fix bugs or – gasp! – add new features) result in lengthy bouts of putting out fires, chasing bugs, releasing hotfixes, and fixing corrupted data?
- Are you forced to run it on servers and/or operating systems older than your new hires?
- Are you dealing with frequent security incidents or worse yet you have no idea if you’ve been hacked?
Technical Debt
The issues we have listed above are often grouped and called “Technical Debt”. Imagine that you had a list of all the technical problems that need to eventually be dealt with and that you knew the exact amount of resources (time or money) that would be required to address them. That is technical debt.
How Much Technical Debt Should You Have?
It’s reasonable for a company to carry some technical debt; paying all of it down would probably be a misuse of resources better directed toward other things. There’s certainly a wide spectrum between crippling debt and stellar status but unless your organization has highly prioritized refactoring, updates, security, and code quality, it is safe to assume that you have some level of technical debt. If you are feeling stuck and some (or all) of the types of technical debt listed above resonate, then it’s reasonable to speculate that you might have too much technical debt and that you should formulate a plan to pay some of (but not necessarily all) of it down.
What is the Cost of Technical Debt?
Okay, so let’s just say that you are carrying a significant level of technical debt. How is it negatively affecting your business? Here are some examples:
- Burnout and high turnover in the dev team
- Inability for key tech people to take time off
- Recruiting new employees is difficult
- Frustration with (outsourced) dev team currently supporting system(s)
- Difficulty innovating, struggling to develop new features
- Struggling to upgrade any part of the systems
- Knowing operations could stop if your software stops working
- High risk of security incidents
Simple Steps to Address Technical Debt
Now that we have broken the problem down into more manageable pieces let’s take a look at a simple three-step process for addressing it.
1. Code and Usability Audit
The first step is simply to thoroughly examine the codebase and usability (UX) of the system. It is tempting to skip this part and just go off what you already know but this risks overlooking large underlying issues. If you are starting a long-term (multi-year) effort to course correct it should be done with the best information available.
Audit Services2. Building a Roadmap
Now that you have an extensive list of the most significant deficiencies in your system it is time to start prioritizing and planning. It can be tempting to prioritize new features or a fancy new design but sometimes you need to focus on the less glamorous parts first. It’s like spending $10K on a furnace rather than $10K on furniture. No one will see the new furnace, but it’s critical to keeping your house livable and can even pay for itself in increased efficiency. That’s not to say that user-facing improvements can’t be considered but it’s important to be judicious and consider importance in other ways than just making things look new.
3. (Re)Building a Solid Foundation
It is important to establish clear standards before you proceed with refactoring and rework otherwise you are just heading towards the next crisis. Standards should include:
-
A dated architecture approach
-
Testing plans (manual and automated)
-
A clear plan for monitoring, security, performance and maintenance
- Read more here: Managing Mission Critical Systems
-
A process for ensuring ongoing code quality using techniques such as:
-
Peer review of pull requests
-
Automated scans
-
Build Automation in the form of Continuous Integration (CI) and Continuous Deployment (CD)
- Include safety measures to prevent deployment if scans/tests fail
-
-
Ongoing measurement of performance and code quality to:
- Prevent slipping back into old habits
- Provide measurable improvements and track return on investment (ROI)
-
An investment of resources to execute the plan
How Can Lelander Help?
Okay, we are pretty passionate about freeing people from the prison of Technical Debt and we have a lot of experience with it – but we would also love to be the people to help you do that work. So, if you are interested in working with us here’s what that looks like:
- We start by performing a Code and UX Audit, preferably involving some brief interviews with the main stakeholders, delivering an audit report with the major issues and recommendations
- We work with you to prioritize what issues to address and figure out a manageable budget and timeline to resolve concerns delivering a roadmap of prioritized planned improvements
- We provide a team of developers and a project manager to work with you to either handle the entire project and/or provide guidance to your existing team delivering measurable improvements on a regular two week sprint schedule
- We facilitate a recurring (quarterly or annual) review of the system status, delivering a summary of improvements made and issues remaining