Tech
Refactoring vs. Rewrite - Which is a Better Option ?
Refactoring vs. Rewrite. When to Refactor or Rewrite Your Code? What factors should you consider before the final decision?
Refactoring vs. Rewrite. When to Refactor or Rewrite Your Code? What factors should you consider before the final decision?
Written by
Did you know that in companies with 100+ developers and/or an active codebase of 500k+ lines of code, maintenance accounts for more than half of the entire development budget? That’s a lot, right?
At MasterBorn, we're quite new to the topic of technical debt management. Most of our software developers write brand-new code. But recently more and more clients come to us with an already existing codebase that usually requires refactoring or a total rewrite of the legacy system.
People come to use with projects that require a lot of thought and some really hard decisions to be made. These usually touch upon key business decisions - adding new features or slowing down a bit to pay the technical debt.
In the past, deciding to refactor vs rewrite was easier because we were working on our product rather than consulting on someone else's old code or old system that we know very little about.
As a CTO I tried to find a solution that would help us approach such cases in our software development projects. And note that we've stumbled upon teams that had little to none of the application-ready code or already running the app with live customers even before we made the decision about refactoring.
The main goal of engaging software developers is to ultimately sell the product. Sometimes, it just so happens that you need to add functionalities quickly by pivoting them. But most of the time, it comes with one serious cost: technical debt cost is your source code as it's built to be delivered ASAP.
After all, to rewrite the application from scratch means losing all the money and effort invested in your current application. Not to mention pulling the rug from your customers' feet.
Deciding to refactor vs. rewrite is a tough call, but some businesses are brave enough to rewrite their apps (and stand to reap many benefits later on from that decision).
Most of the time, at MasterBorn we tend to go with refactoring, improvement, and applying changes - unless the existing source code quality is really low (I like pasta but Spaghetti Code is not my favorite dish…). In such a scenario, we tend to rewrite the code in parallel.
Building software isn't just about fun. It's also (and tbh: always) about the money.
Whenever teams are concerned about deadlines and/or have a strict limitation on their budgets, they tend to go with refactoring rather than a complete rewrite of the existing application. This is a natural choice given the limitations you're dealing with.
We're talking about some serious architecture problems, buggy apps, or features that just aren't working.
Technical debt costs real money. An analysis of debt carried out by CAST Research Labs (CRL) in 1400 applications at 160 companies revealed that an average-sized application of 300k lines of code has $1,083,000 worth of debt. That's $3.61 per line of code!
Are you running out of time? Who doesn't? Is your goal to bring the app to the market as fast as possible and your deadline is fast approaching?
If that’s the case then you probably don't have a choice other than refactoring the app. Businesses usually end up in this situation when they choose to add new functionalities that the app needed from day 1. Their development team didn't have time to implement it due to various limitations.
When you're very limited in time, refactoring vs. rewriting isn't a question anymore because refactoring may be your only solution (but in some cases you won’t have time even for that).
You can't get great bread without a seasoned baker. If your team is highly inexperienced or its actions led you to the point where you can't move forward easily, then going for a rewrite might be more of a problem than an actual advantage. You also want to make sure that the same people don't work on your software anymore (at least not alone).
Get informed about the most interesting MasterBorn news.
You've been successfully added to our list! We'll keep you updated with any news about MasterBorn.
Consider this quote from Albert Einstein: “The definition of insanity is doing the same thing over and over again, but expecting different results.”
He was a physicist, not a software developer. But he sure knew what he was talking about.
In this scenario, finding a more experienced software developer is much more efficient. This person could lead your team and help in rewriting your app to add new meaningful changes to your system.
But watch out for this scenario: super experienced people may tend to overthink their solutions, which may lead to prolonging any chosen way.
As I mentioned before, you need experienced software developers and other specialists in the right place. But don't forget about their "team factor."
You know what they say: nine women can't give birth to a baby in a month, and that applies to developers too. In fact, it can lead to the opposite - especially if you take people from the bench or worse, outsource them.
"Throwing resources" at complex issues might not do much good to your code's complexity. Also, you will have to waste a bit of time to make sure that new people are integrated with the team and introduced to the code. They will also need time to think about proper solutions and where/how to implement them. Not to mention acting according to company values and really fitting into the organization’s culture.
The general conclusion here is that you need people who will be working on solving things efficiently and you need to trust them that they know their trade - regardless of whether you choose to refactor or rewrite your system.
To me, it's a tie.
One magical sentence works really well here: "It depends." As you can see, many factors come into play when you're deciding between rewriting and refactoring. It's smart to take them all into account when making your final decision.
Neither refactoring nor rewriting is a "no brainer" decision when you're setting up a new business goal in terms of software development.
You need to factor in EACH one of the above. And add to it any other factors that are to your business or industry when making your decision, such as:
At MasterBorn, we always try to find the best solutions for our clients. When choosing to rewrite or refactor their system, we always give them a detailed explanation of why one option is better than the other and what they stand to gain by choosing it.
As I mentioned, most of our solutions are built from scratch and technical debt isn’t an issue now. But if I were to gather the existing client codebases, then the tendency would be as follows: 40% refactor and 60% rewrite. The biggest issues that occur are:
If you're dealing with a serious problem in your application and you're not sure what your next step should be, get in touch with us at hello@masterborn.com We'll take a close look at your project to tell you whether your developers failed completely or there's still something to be salvaged here by refactoring your code.
Partner with world-class experts who understand your challenges, deliver seamless solutions, and support you every step of the way.
/5
/5
Copyright © MasterBorn® 2024
