As software developers, we strive to write elegant, well crafted, easy to understand code. We follow principles like DRY (Don’t Repeat Yourself), KISS (Keep It Simple Stupid) and YAGNI (You Aren’t Gonna Need It). We write code that is extensible without being esoteric, performant without being overly complex and reusable without being unmaintainable.
But there are times when code can get ugly. Fast approaching deadlines, last minute requirement changes and limited budgets require trade offs. Outdated business practices, new modules and integrations can cause layering of features on top of pre-existing ones. Lack of training, guidance and foundational architecture can cause mistakes or bad assumptions.
Whatever the cause, addressing tech debt, cleaning up messy code or adding stabilization should be a standard practice to maintain your product’s health. How often you do this and what approach you take depends on a number of factors. Some key things to look out for are:
- Cost – Is it more expensive to maintain, or rewrite?
- Bugs – Do enough bugs make the tool seem unstable to users?
- Outdated Technology – Is it no longer supported by vendors or developers?
- Future Features – Is adding a new feature difficult or risky?
If any of the above are true, you might want to consider refactoring.
In contrast, there might be reasons to steer clear of refactoring.
Some of these factors are:
- High Risk – Hold off if you have critical business deadlines coming up. (Refactoring needs attention.)
- Just Because – Keeping up with latest and greatest technology because it is shiny and new. (Resist the urge!)
- When a Full Rewrite Is Better – Sometimes it is better to just write from scratch, it can even be cheaper in the end.
Just like you planned your product design, plan your refactoring efforts. Think – what got you here in the first place; what you can do to prevent it from happening again?
Better to have solid code up front, than to clean up messes later.
How can you minimize the need to refactor?
- Create POCs/Throw Away Code – Creating a playground will help you test your ideas without committing to a final deliverable. This will allow you to move fast and be adaptable.
- Have Good Design Sessions – Diagram twice, code once. Giving your product some thought up front will provide innumerable benefits in the future.
- No ACs, No Code – If you are being pressured to write code without clear guidelines or requirements, push back. It is better to fully understand a business need than to make assumptions or try to fill in the blanks.
Finally, remember – just as your business needs evolve, so does your software. It needs regular maintenance and care for optimal performance and efficiency.
Have some messy code you don’t want to deal with? Reach out to us – we’ll help apply our refactoring best practices on your product.
