In our recent post, we talked about technical debt and the impact that it can have on your organization – regardless if you're a startup or the engineering department of a Fortune 500.
Now it's time to talk about something more uncomfortable. No, we're not going to discuss burn rate (in this post!) but it's a topic that should be on the mind of every founder and product owner.
Refactor. The word alone strikes fear in the heart of engineers and CEOs alike. In software development, a refactor is when a project is completely rebooted. If you think this is costly and time-consuming, well, you're right.
In this post, we are going to dissect when to fix technical debt, when to fix certain areas, and when to completely refactor a project. Are you ready?
The decision to refactor boils down to a few key indicators: cost to support existing solution, limitations of existing solution, and business value gained by a refactor. To chat with software development exports about refactoring, contact Tragic Media today.
When to fix technical debt
There are times when your team should fix existing technical debt and keep your current system. There are three situations where we recommend fixing things, rather than throwing away and starting over.
First, you should fix technical debt when the initial investment into the project is high and the returns to moving to a new system are low. This scenario is straightforward – a refactor is expensive and there needs to be a clear return on your investment by suggesting this course of action. You should not do a refactor for a 10% improvement!
Second, you should fix technical debt when its concentrated into a single area of the codebase. For example, if you only have tech debt in a specific area of your app, it's not worth doing a complete refactor. As an added benefit, fixing the worst performing area of your application can can create improvements across the board (e.g., addressing the bottleneck).
And third, we recommend fixing your technical debt if it's concentrated in the user interface (UI) or user experience (UX). Generally speaking, you can rework the UI/UX without a complete software refactor, but this will depend on how deep your technical debt is.
When to refactor your project
Similarly, here are three clear signals that point towards a complete refactor. If any one of them apply, your team should seriously considering stopping and evaluating whether to refactor.
First, if your team is spending more time keeping your system running than improving the system, it's time for a refactor. For example, one of our clients had a system that was requiring a minimum of 10 engineering hours a week just monitoring and fixing issues to keep the system from crashing.
Second, when there are large security vulnerabilities that cannot be patched, it's time to refactor. For instance, when platforms reach the end of life (EOL) and no longer are supported, you need to be proactive and plan to refactor. Running on outdated hardware, operating systems, or platforms is dangerous.
And third, when there are significant gains available by moving to a more modern technology stack. When there are clear benefits in terms of speed, scalability, security, new functionality, or cost, it's more likely than not that you should opt for a refactor.
The client mentioned above was not only paying for constant engineering time to support their system, but they also had massively unnecessary server costs due to how the technical debt had grown over the years. By refactoring their system, we were able to save them over $500 per month in hosting costs only!
If you are going to refactor, do it right
Now that you are going down the path of refactoring, you have to follow the right steps. We highly recommend taking the time to research the available frameworks and best practices to ensure your team is aligned. Additionally, agree upon the technical functionality and outline the system before the project starts. This will ensure your project starts off on the right foot.
Next, take the time to conduct user experience research to ensure your UX improves and that you properly solve any short-comings of existing systems. You do want to make sure your application is better at the end of your refactor. Your new system should solve additional problems beyond just the technical debt to leave your users even more satisfied.
And lastly, you need to document everything. One of the biggest issues with your old system is a lack of documentation, so don't let that be an issue with your new investment! Document processes, code, and designs. Move deliberately so that you can save time in the long run.
How to refactor with no downtime
Now that you know when to refactor, let's discuss the best way of refactoring your project: refactoring your platform or application without any perceivable downtime.
This is the most seamless approach for users and requires, more than anything, plenty of upfront planning. Your team has to be focused on building the new system, creating a solid migration path, and being able to quickly revert if things do not go as planned.
In order to achieve 100% uptime, we suggest launching the new system on its own servers before running a data migration script, then updating the DNS, then running a post-migration patch script so that your team can add in any data that was added by users during the brief data migration.
Moreover, test your migration and have a fail-safe plan in place. If things go south for some reason, revert early and regroup rather than leave your users having a bad first experience with your new system.
How to plan to not refactor
Congratulations on your shiny new system! It's finally stable and users are loving the experience. Now there is one more step in the process – keeping it performant.
You can eliminate future technical debt by following the Tragic Media Technical Debt Checklist:
- Thou shall not rush out features
- Thou shall keep standard release processes
- Thou shall follow QA and DevOps best practices
- Thou shall keep systems maintained and software updated
- Thou shall introduce team audits
- Thou shall introduce security audits
- Thou shall keep clear and up-to-date documentation
Conclusion
You've made it! You have learned about when to fix technical debt and when to refactor, while also understanding the best practices in refactoring your software project so that you increase stability, save money, and create a seamless experience for users.
Software development is challenging but we hope that these steps have been informative as you build your product roadmap for 2020. Be sure to follow the Tragic Media Technical Debt Checklist carefully. Don't say we didn't warn you!
As a recap, the decision to refactor boils down to a few key indicators: cost to support existing solution, limitations of existing solution, and business value gained by a refactor.
To chat with software development experts about refactoring, contact Tragic Media today.
