DATEV Nine-Nine | Xmas-Blog: Refactor vs Rewrite
By: Matthias Alt, Stephan Bierwirth & Gerrit Riesch
Intro
In the fast-paced world of software development, two crucial concepts often come into play when it’s time to enhance or update existing code: rewriting and refactoring. In this year’s Xmas blog we want to see how our detectives Amy and Jake think about this topic.
Amy is a methodical developer and therefore her coding style resembles the meticulous planning of a Christmas dinner with friends and family. Refactoring, just like perfecting the family’s christmas cookie recipe, involves improving existing code without altering its essence. On the flip side, the spontaneous Detective Jake embodies code rewriting, similar to throwing away the old recipe and just creating a new one. Often it’s a tough decision and our detectives Amy and Jake represent the two methods in this blog. Therefore, developers must channel their inner Amy and Jake to decide which approach will work for a specific use case.
Detective Refactor:
Amy, who we all know for her precision and methodical thinking, is a big fan of the refactoring approach. Refactoring involves making incremental improvements to the existing code while preserving its overall structure and functions. Amy’s attention to detail and commitment to continuous improvement align perfectly with the essence of refactoring.
So, when to channel your inner Amy?
● Code Smells: If there are minor issues like duplicated code, inefficient algorithms, or unclear variable names, a series of small, systematic changes through refactoring can eliminate these smells more efficiently than a rewrite.
● Maintainability: Like Amy keeping her workspace impeccably organized, refactoring is necessary for maintaining a clean and manageable codebase over time.
● Performance Boosts: When you need to enhance performance without rewriting the entire code, Amy’s approach shines. Small, targeted optimizations can make a significant difference.
● Time Pressure: If you have not enough time or resources to do a complete rewrite you might first have to look into refactoring.
● User Impact: Consider the impact on end-users. If the codebase is stable, and users are happy with the current state of the application, refactoring might be a more gradual and less disruptive approach compared to a rewrite
However, much like Amy’s slow but steady advances in her carriere, refactoring requires patience. It might not be the way to solve all problems at once and can be less fun than starting fresh, but the long-term benefits of a more maintainable and efficient codebase are worth the constant investment.
Sergeant Rewrite:
Jake, known for his impulsive and daring nature, is the embodiment of the rewrite strategy in software development. A rewrite involves throwing away the existing code and starting from scratch. Much like Jake’s spontaneous nature, this approach can be risky but may yield dramatic improvements — and can be way more fun.
When to channel your inner Jake:
● Major Problems: When the existing code is riddled with flaws that are too big or complex for refactoring or builds upon outdated technologies, a rewrite might be the best idea.
● Innovation: If you have a big idea in mind or when there are new requirements that change the entire app you can use the rewrite approach along the way .
● Developer Experience: If the code is becoming worse to deal with with every refactor and developers are quitting after getting in contact with it you should maybe consider starting fresh.
● Testing Coverage: Evaluate the current testing coverage. If the code lacks comprehensive test coverage, a rewrite may provide an opportunity to implement robust testing practices from the ground up.
However, this strategy can backfire. A rewrite can be time-consuming, costly, and may introduce new bugs and in the worst case scenario you end up with an even worse code base than before.
The Pontiac Bandit Paradox
Doug Judy aka the Pontiac Bandit, is a beloved but sometimes exhausting character who keeps coming back again and again and always brings some trouble with him. Technical debt is our Pontiac Bandit, tempting developers to keep patching up rather than committing to a full rewrite. But as Doug Judy always reminds us, “It’s not goodbye; it’s see you later.” Similarly, rewriting code may be a farewell to old problems, but the Pontiac Bandit of technical debt might return as well.
“Refactoring is like the temporary truce with Doug Judy — a short-term solution to keep things running. Rewriting is the pursuit of a permanent solution, but beware of the Bandit’s return!”
Imagine Jake and Amy planning another epic heist — just like our Halloween Heist ;) -, but this time it’s the heist of legacy code (sounds like another Halloween story). Developers must weigh the pros and cons of refactoring versus rewriting. Refactoring may be the silent infiltrator, subtly improving the existing system, while rewriting is the SWAT-Team, taking everything apart. But again: Don’t forget the Pontiac Bandit of technical debt!
Conclusion
Remember, the arguments for rewrite and for refactoring should always be considered together, not in isolation. The decision to refactor or rewrite often involves a balance of technical, business, and resource considerations. Always prioritize the approach that aligns with the long-term goals of the project. For a rewrite it is essential to have someone in the team which is aware of the domain and can advise the developers on requirements. Otherwise refactoring after implementing some integration tests could be better due lack of time and resources. If refactoring is the way you want to go then it could be very useful to have at least some integration tests to make sure that the application features work like before the refactoring.
In the world of software development, the choice between a Jake Peralta-style rewrite and an Amy Santiago-style refactor depends on the specific challenges you’re facing and they complement each other just like our two detectives. So, whether you’re dealing with code crimes or debugging dilemmas, we wish you best of luck, success and a Merry Christmas!
We hope you enjoyed our blog and we would love to see you next time!
Your three DATEV Nine-Nine detectives,
