Refactoring vs Rewriting a Mobile App from Scratch – Comparison for App Owners

Software engineering projects, as volatile in nature as they are, are necessary for releasing whole systems and delivering your product to end-users. They are the beasts every Product Owner has to try to tame.

During their lifetime, projects change developers and even whole teams. This is why, sometime in the future, it’s possible you are presented with a simple choice, yet one with far-reaching consequences: should I decide to rewrite or refactor the existing software?

What is project refactoring?

You might have stumbled upon the notion of code refactoring. There are numerous definitions with varying levels of complexity, usually directed to people with different technical knowledge and command of skills. From this point onward, we will talk about the most basic one and not delve into technical details too much.

So, what does it mean to refactor the whole project? Refactoring basically means to restructure the existing project functionality in order to make the future updates easier. This can include using newer versions of third-party libraries and technologies, as well as lowering the overall code complexity level. Small parts of the functionality can be rewritten but, mostly, it will involve tailoring the system functions one by one so that these features adhere to the new architectural approach.

A common misconception is that refactoring has a defined end, after reaching which the app will magically be well-structured and ready for effortless implementation in the future. In fact, refactoring is a development technique, not a project.¹

Normally, we should differentiate the notions of code refactoring and a “massive cleanup effort”. For the sake of simplicity, I’ll cling to this informal terminology and use the word “refactoring” to define a big process launched upon receiving a poor quality codebase when, for some reason, the code shouldn’t or wouldn’t be rewritten from scratch.

You may also like: Mobile App Testing – Introduction for Product Owners

What is project rewriting?

On the other hand, the rewriting process of a project means what you might have guessed – rewriting the code from scratch. During a rewrite, the coding process basically starts anew. The main advantage of rewriting is that the developers will not be in any way limited by the existing code. It is then easier to use more up-to-date technologies.

Contrary to refactoring, rewriting an app gives the development team a clean slate. There’s no inherited legacy code to work with anymore, whereas the app refactoring will most likely leave some of it. This is why most developers will encourage project rewriting instead of refactoring. Let’s sum up:

Why is it necessary to decide either refactoring or rewriting?

At first glance, it may not make sense to make such a decision from a financial standpoint. But play the initial scenario out:

Your app went public and the recorded crash rate statistics are looking good. Users are quite pleased with how the app works but would like to get new features. Your app is now running on tens of thousands of mobile devices across the world. After another period of healthy, organic growth, the stakeholders decided it’s high time to introduce a new feature to the app. They believe it will have a huge impact on app usability and user experience. It makes perfect sense to add this new feature. Unfortunately, the company who has previously been responsible for delivering an implementation is either no longer there, is unavailable for more work at this time, or, for some reason, you were not happy with their work.

As a Product Owner tasked with searching for a suitable development team to continue working on your product, you have probably been advised to rewrite the app numerous times. Does it even make any sense? Isn’t the company just trying to rip you off and secure a potentially longer-lasting contract at the same time? In what way can it possibly benefit your company and the existing product? This and many other perfectly reasonable questions come to mind.

In fact, the reasons to consider a “start from scratch” or a large refactoring effort aren’t scarce at all. Perhaps the newly requested features are incompatible with the existing architecture? Maybe the codebase is simply a mess but your team inherited the project instead and are now the ones responsible for it? You might find some of these problems relatable but precise problem definition is not what matters for making a point here. What does matters is that you are dealing with legacy code and that you can be sure this legacy code will seriously hamper the development process at some point. It can manifest itself in the following impediments:

• The developers gradually grow tired and unmotivated from having to work on a deteriorating codebase where things might easily break.
• The new features rollout tempo slows down quite a lot due to technical debt, ultimately rendering the code impossible to work with. New features take too long and cost too much because of the interdependence of the codebase (new features cannot be isolated, and therefore affect existing features).
• The app is more and more buggy and unstable, resulting in outraged users and, in turn, very low app ratings and possibly even poor user retention.

To sum up:

What is legacy code and why does it even exist?

First of all, let’s make sure we use a common definition. Legacy code isn’t necessarily a means of describing something broken or buggy. It usually means the software is still operational and serves its purpose for the most part. Some bugs might be there but they are far and between. Legacy code might simply mean the software is built around a somewhat obsolete ecosystem or using out of date techniques. Thus, the software might not be easily modifiable to feature new business requirements. Legacy code starts to creep in for a few main reasons:

• Missingor low-quality tests. Every developer is reluctant to introduce changes in a complicated codebase for fear of breaking something and ultimately making things worse. The risk of breaking things becomes increasingly large as the system gains new intertwined functionality.
• Neglected regular maintenance. Usually, code doesn’t get taken care of properly because it’s difficult to get it running or because it’s become so complicated that it gets hard to work with. The two main reasons for the codebase quality deteriorating are low separation of concerns and introducing numerous quick fixes and special cases unaccounted for during architecture planning.
• Source code is no longer accessible. Companies sometimes lose access to the source code of a vital program over time. The end result is that there’s a system in production that can’t be changed because there’s no code. That part of a system can either be treated as a “black box” and worked around in upcoming special cases, or it can be rewritten.
• Pressing deadlines. Many developers don’t feel confident, even in their backyard, if they are pressed onto with tight deadlines. There’s really no time to properly manage code quality. Over time the technical debt gets so large it interferes with adding new features, gradually paralyzing the whole project. It’s crucial for the developer to take the matter in their own hands and inform the management that their way of doing things will eventually be harmful to the project.

“A software group starts writing a piece of software and they’re productive at it. Over the course of time, as they hustle to get features out the door, they make a mess, always vowing to clean it up later when they have the time. But, they never have the time because, with every delivery cycle, they’re able to ship fewer things because of all the problems that have developed in the code. Eventually, features slow to a crawl, and developers are increasingly miserable.” – Erik Dietrich.

Pros and cons of refactoring an app

The most noteworthy advantages of code refactoring:

• You can take things slowly and as separate problems, one small piece at a time. This is immensely helpful in terms of preserving app stability.
• If you abandon the process partway through, you will still benefit from it in terms of a cleaner codebase. Contrary to refactoring, a rewrite must be completed to offer any expected benefits.
• Updates can often be shipped to users in milestones, rather than all at once a fair amount of time later. It’s possible to continue to deliver updates (not just bug fixes) to the users while still seriously improving the system codebase.
• Any new features and bug fixes can be thoroughly tested regressively against the existing application.
• A current project will have had its business rules refined with countless hours of actual user feedback, bug fixing, and regressive testing.

Disadvantages of app refactoring:

• In refactoring it is harder, or most of the time impossible, to change technologies or frameworks.
• While refactoring can improve a piece of code, it cannot easily fix underlying architecture problems.
• One of the biggest challenges of refactoring is that, after doing the modifications, the system should meet the exact same business requirements as before. Therefore, refactoring usually involves a high amount of testing and debugging, further increasing the overall costs of such an operation.
• Refactoring usually doesn’t involve a completely new stack of technologies. Thus, it might prove to be harder to find motivated developers to do it.

Pros and cons of rewriting an app

Deciding to rewrite an app from scratch comes with several useful perks. Advantages of rewriting the app from scratch are:

• Learning from past mistakes and drawing conclusions. Rewriting the app from scratch, you usually redesign the app based on past experience. There’s a good chance that, if you have experienced developers – and you also have good command of the business requirements – your team will be able to avoid many of the pitfalls and mistakes made by the previous developers and create easily maintainable code. At the end of the day, it will speed you your future app development and maintenance.
• Rewriting code from scratch can open new market opportunities, such as new users, markets, platforms, and technologies. Rewrites eliminate the unavoidable headache of attempting to adjust the old code to meet the demand for new technologies and business requirements.
• Removing unmaintainable legacy code. Debugging or changing hard-to-maintain/unmaintainable legacy code may seriously slow your app development down. Rewriting the app from scratch is a perfect chance to remove these parts of code.
• A new start. Developers get a clean slate. They can use new, yet critically-acclaimed technologies and frameworks. A fresh start like this makes the project motivating and positively influences productivity and overall product quality.

On the other hand, rewriting a project can pose severe problems. Disadvantages of rewriting an app from scratch are:

• If you do only rewriting, without refactoring the existing app, users don’t get frequent updates and, consequently, user retention might get to the lowest levels
• Deciding for a complete rewrite without maintaining the old app at the same time is like giving your competitors a free year or two of a head start, for example on new features. In software development, that’s a lot and entire companies have gone out of business due to poor strategic planning.
• A rewrite must be completed to offer any expected benefits. Releasing an app that has smaller functionality may annoy your users and is a major setback.
• The developer’s capacity devoted to rewriting isn’t used to support the customer, unless there are two projects held in parallel.

Read also a more detailed article about The Pros and Cons of Rewriting an App from Scratch.

When to refactor an app?

“We’re programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand.”- Joel Spolsky

Many developers will no doubt agree with the above quote from Joel Spolsky.² Being over 20 years old, the words have lost none of their relevance, rather the contrary. At the same time, a responsible developer will always take into account what’s best for the client’s business. A working and published product, alongside a glad client, makes up for a far greater dose of satisfaction than a product being rewritten many times and not being released as a result.

When to rewrite an app?

If refactoring the app seems to be the best solution for most of the cases, what are some legitimate reasons for deciding if an app should be rewritten? Let’s look at a few of them. You can consider rewriting an app if:

• The current state of the code is trivial in nature and you are planning a fundamental change in the project’s architecture anyway.
• The original project’s source code has been lost and it’s either impossible or not worth undertaking a complete recovery.
• The vast majority of business requirements and use cases encapsulated in the original product are no longer viable or used.
• There are very few active users of the app
• You have some form of business rules documentation or you’ve decided to maintain the old application and develop the old and the new app in parallel
• The technology is prehistoric and it’s getting increasingly harder to get good developers for it. If a technology is old, there are quite good chances it will have less and less proficient developers, thus making them harder to acquire and significantly more expensive.
• The code has been inherited by a new company, it’s lacking documentation and the code is so convoluted that it renders the project impossible to work with. If the coupling of components in the code is at a very high level, chances are that changes to any single module cannot be fully isolated from other components. Therefore, a refactoring of a single component would result in a cascade of changes not only to adjacent components, but also other components scattered across the whole system.

To sum up:

What is the cost of refactoring vs. rewriting an app from scratch?

Keep in mind that the total cost of redesigning incrementally is, in the long run, almost always higher than doing a complete rewrite, but the impact on the organization and the active users is certainly smaller. The cost of refactoring can be significantly smaller if there’s not really much to be done and the app can get by on minimal amounts of maintenance. If the app will not have many more features to be added in the future and can get easily get by with the current levels of stability, then going for a rewrite is a potentially catastrophic strategic mistake. If that’s not the case and you can justify and defend a rewrite, and you trustworthy developers, then do it.

It’’s important you have the vision of the app in the long run. Do you expect the app to be thriving in the market for years to come? It might make more sense to go with a rewrite instead of refactoring for now and then, in the future, being forced to rewrite anyway. It’s just the sunken cost of refactoring in this latter case.

Generally, the cost of rewriting the application and temporarily maintaining the rewritten application is less than the cost of maintaining the current system over time.

On the other hand, there’s an important implicit cost to rewriting an application. In the time you devoted to a full rewrite, your competitors might have just won an edge advantage over you, updating their solutions with better user experience or a new, highly anticipated feature. Therefore, there’s really no universal answer – each case has to be analyzed separately, preferably with mobile experts.

The takeaways

Projects developed and maintained over long periods of time usually eventually enforce the decision: whether to refactor or rewrite the app. Keep in mind that a mere time frame and some intuition are not an appropriate measure of such a drastic decision to scrap an app or rather refactor it. You must have clear, defensible, and well-understood reasons to take on this course of action.

Don’t think in absolutes for refactoring vs. rewriting code.

Moreover, you should make sure you have a mature team of developers who are willing to put themselves in your shoes. You need the kind of people that won’t just unequivocally push towards a complete rewrite for their own, temporary comfort.

Related posts