walls.corpus

By Nathan L. Walls

Favor refactoring over rewriting

Patrik The Dev, on Twitter:

(W)hat’s your reasoning for PHP? The industry is generally moving away from it (except huge existing codebases) so I wanted to hear your thoughts

Marco Arment on Twitter:

PHP has ALWAYS lived up to its role in my stack as the fast, conservative, ubiquitous platform that just works and needs no server babysitting.

PHP lets me sleep at night, spend time with my family, or go on vacation without worrying that it’ll fail.

It has never failed me.

If your codebase works for you, there are no benefits to trying to rewrite it in a new language or framework.

Scaling horizontally indefinitely would be less expensive than rewriting.

The web app side of the industry has had, for multiple years, a tendency toward rewriting software once a language or framework becomes less popular. Meaningfully, it’s fairer to say, “when a language or framework becomes less meteorically popular.”

A memorable example were teams abandoning Rails applications and reworking them in NodeJS. I think a lot of the growth of front-end frameworks in the last 10 years has similarly encouraged chasing popularity instead of identifying and sticking with something that works.

I started my software career in 2000 and over the past 22 years, I’ve been part of a lot of rewrite projects. Only rarely have any of these projects provided a benefit to the team or organization at large. More frequently, the rewrites were an expensive distraction from operating and enhancing currently working (and generally stable and profitable) software.

There are conditions where rewrites make sense. But, they’re less rewriting the application and more refactoring specific parts of the application to something else. Would I rewrite my Rails application to Go because “Go is more performant”? I would not. I might, however, identify some critical pieces of expensive processing with a well-defined scope that would benefit from a substantial speed increase and that particular piece, I might rewrite. More likely, I would examine my present language and framework for missed opportunities for performance optimization first and then, and only then, would I consider the value of a rewrite.

Again, rewrites are expensive distractions and only in vanishingly rare circumstances are they worthwhile. Refactoring and performance work, however, has higher utility, better odds, and accordingly better payouts.

In summation: Favor refactoring within your application’s existing language and framework before you consider rewriting parts of the application in new languages and frameworks. Favor rewriting select parts of the application over rewriting the application wholesale.