Favor refactoring over rewriting

Sunday, 7 August, 2022 — software

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.

Full stack teams vs. full stack developers

Saturday, 6 August, 2022 — software

Allen Holub:

The idea of a “full stack developer” is an insane fantasy, given the complexity of modern software. That’s why we have full-stack teams. Every skill needed to get an idea into our customers hands is represented on the team by at least 2 ppl, & everybody teaches everybody else

This is true-ish. But, it’s far from an absolute, and accordingly, the sentiment is incomplete (Twitter’s design inherently limits nuance.). In my mind, the distinction is in where and how teams invest in complexity and specialization.

What do I mean by that? It breaks down a few different ways:

• Teams with very complex application stacks and deployment mechanisms likely need a lot of internal specialization within the team
• Teams with simpler application will more likely have “full-stack developers” or, what I think is the more applicable term, generalists
• Teams can outsource a lot of complexity to limit where they need specialized knowledge
• Teams frequently insource a lot complexity out of aspiration vs. necessity

Here’s where I see some differences between insourcing and outsourcing from a team. I’ll use a Rails application as an example:

• If the Rails application is a monolith, using server-side rendered HTML, deployed to Heroku, I think the team can primarily be composed of Rails generalists with some specialization for CSS and HTML and also for Rails performance optimizations.
• If the app instead uses a heavy front-end JavaScript framework like React, the team will likely need a specialist in JavaScript and React
• If the app uses other distributed systems within the application or has more complex job processing needs, the team will likely need a specialist in asynchronous job processing, publish/subscribe buses, and job repeatability/idempotency
• Moving towards further complexity, the application is deployed to a cloud provider with Kubernetes, maybe there’s a discrete database vs. using a hosted solution, and the team is now looking at needing specialists conversant in those topics as well

Particularly in the last case, an on-team specialist may not necessarily be a person responsible for maintaining a consumed service. My own team closely matches that last bullet point, but no one on the team is managing our Kubernetes or Google Cloud infrastructure. Our company’s systems engineering team is directly responsible for those items, but our team-based specialists are familiar with how to successfully use those services.

In the first case, we’re looking at a pretty good range of potential teams. Everything from hobbyist applications to solo or paired founders on up to small companies or well-focused teams in a larger engineering organization.

Other things a team may insource vs. outsource:

• Continuous integration
• Code quality metrics, linting, and automated feedback
• API documentation and publication

The overwhelming issue I see with Holub’s sentiment is the assumption that applications and therefore teams need that complexity and the specialization that comes with it. I agree that some teams do, but I suspect many teams don’t. Accordingly, those teams would be better off not taking on that complexity absent very compelling technical and business reasons for doing so.