By Darren Beale

Imagine that you accept a new job and inherit a legacy PHP web application… or maybe it has always been there hiding in the shadows. When the original developer left, they didn’t leave behind any documentation and your current team thinks it’s a mess. You know that there are probably security vulnerabilities and performance issues, but you’re not quite sure how to proceed in remedying the situation.

You could rewrite the entire application using a more modern framework or new language, but you would have to justify the budget and divert resources. On the other hand, you could refactor the application, but it’s hard to know where to start and it might take even longer to bring the application to an acceptable state.

Let’s take a look at the pros and cons of each of these approaches and how to decide between rewrite and refactor.

What’s the real problem?

It’s important to understand your motivations for refactoring or rewriting an application. Without a deep understanding, it’s difficult to determine the best path forward.

Joel Spolsky cites three common problems in his popular blog post, Things You Should Never Do, that made the case against rewrites back in 2000:

  1. Architecture Problems: The code isn’t organized and it makes everything more difficult. For example, model logic may be sprinkled across views or similar functionality may exist across many modules. These problems are best solved by refactoring the code rather than completely rewriting it.
  2. Efficiency Problems: The code isn’t very efficient and it’s slowing everything down. For example, you may have a N+1 queries that slow down an entire application by running repetitive database queries. These problems can be solved by refactoring the specific piece of code or rewriting the section that’s causing the issue.
  3. Code Smell Problems: The code isn’t styled uniformly and it’s ugly and difficult to read. For example, you may have some variables in camelCase and others in snake_case. These problems can be solved through refactoring rather than rewriting—in some cases, even using an automated linter.

On the other hand, a popular StackOverflow thread highlights some problems where it might make sense to rewrite an application:

  1. Deprecated Frameworks: The framework that you’re using has been deprecated and no longer maintained. For example, an open source framework may no longer be maintained and have numerous security holes. These problems may require a rewrite to ensure long-term security and maintainability.
  2. Excessive Complexity: The code may be too complex and interconnected to refactor. For example, the coupling of components may be so high that single components cannot be isolated, or refactoring could involve a lot of infrastructure changes that would require a rewrite anyway.

It’s important to take the time to audit your code base and understand these problems before making a decision between a refactor or rewrite—especially given the high cost of making the wrong decision.

What is refactoring?

Refactoring involves making modifications to the code over time to improve the overall quality and make it easier to maintain. For example, a developer might decouple components to make the code easier to read and more maintainable. This kind of refactoring can be integrated into existing developer workflows.

Benefits of refactoring

  • Cost Effective: Refactoring enables you to keep all of your existing code, which could save you money. You don’t have to rewrite functionality that is already working.
  • Immediate Effect: Improvements can be made on-the-fly with the existing code base. You can continue delivering updates and bug fixes while improving the code base.
  • Existing Resources: You can continue to use your existing developers and infrastructure since you’re not changing any underlying technologies or frameworks.

Drawbacks of refactoring

  • No Big Changes: It’s more difficult to make big changes, such as implementing a new framework, if there are inherent problems with them.
  • More Testing & Debugging: Refactoring involves a lot more testing and debugging, which is less appealing to developers that enjoy creating new features.
  • Behind the Scenes: Refactoring doesn’t typically produce visible changes in your application, which can make it difficult to justify the cost to non-technical management.

What is a rewrite?

Rewriting involves discarding the previous code base and starting over with a blank slate. You can change the language and framework and ensure everything is done right from the start. For example, a development team could rewrite an entire PHP application in a new PHP framework, or new languages like JavaScript, Python, or Ruby.

Benefits of rewriting

  • Blank Slate: Rewriting an application gives you the opportunity to choose the language, platform, patterns, and tooling of your choice. You don’t have to work around other people’s choices made under different conditions.
  • More Enjoyable: Developers are often more excited about a rewrite since it’s an opportunity to learn new languages and frameworks, and there’s more feature development than testing and debugging.
  • Easier Justification: It may be easier to justify a rewrite since there’s a visible change to the application. On the other hand, it requires buy-in from both managers and end users (given the potential change in UX).

Drawbacks of rewriting

  • More Costly & Time Consuming: Rewrites are usually more time-consuming than refactoring since all existing functionality must be duplicated. In addition to longer lead times, this can significant increase the cost compared to refactoring.
  • Split Focus: Developers must split their focus between maintaining the legacy application and developing the new application.
  • New Requirements: You may require new developers or tooling to support major rewrites, which could mean changes to the existing development team.

Rewrite Refactor PHP

What’s the right option?

There’s no doubt that most developers would choose to rewrite an application rather than refactor it. After all, the work is more enjoyable and they get to start from a blank slate. It’s a lot harder for them to read code and refactor it than write code from scratch using their own styles and patterns. But that doesn’t necessarily make it the best option.

On the other hand, there are many examples of failed rewrites:

  • Microsoft’s Pyramid project sought to rewrite Word from scratch, but it failed miserably and turned into a financial disaster. Fortunately, the company never stopped working on the old code base and had something to ship.
  • Arago tried to rewrite dBase and Quattro Pro from scratch, which both turned out to be disasters that increased market share for Microsoft Access and other competitors.
  • Textmate took six years rewriting their application and went out of business before it could launch, eventually open sourcing the application.

We believe that a comprehensive audit is the first step in deciding between a refactor or rewrite. The audit should take a look at the existing code base to determine what underlying problems exist and assess whether they’re best solved via a rewrite or refactoring.

If it’s possible to refactor the application and avoid a costly rewrite – which in our experience it is almost always the case – then you may want to consider outsourcing these tasks to a third-party to keep your existing developers focused on feature development, where they are likely happier and more productive.

We specialise in helping businesses turn neglected legacy PHP applications into modernised applications that are understandable and enjoyable for developers to work on.

After auditing your code to identify any security risks and performance issues, we provide a comprehensive report to help inform your decisions. Then, we make your website portable by decoupling the code from the infrastructure. And finally, we ensure that it’s secure, protected, and updated through regular refactoring and maintenance.

If you’re interested, contact us for a free consultation and learn how we can make your application more maintainable.