Is this news to anybody? Feels like I should just point AI and several “foundations of software engineering” and have it churn out blog posts for each chapter.
This rings so very true. Have been in the software business for too many decades and having inherited other people's code many many times, there is always the decision about what to do going forward. Leave it running, refactor it gently or rip and replace. Each has it's own set of traps that need to be carefully considered.
A perennial insight which has been articulated many times before. This feels like one of those stages all engineers pass through at some point in their growth journey. Chesterton's Fence and all that (or Joel Spolsky's "never do full rewrites" advice).
The "When touching it is the right call" is the tricky part, because it contains this very subjective exception: "Every new feature costs three times what it should because of the design, and you can show the trend."
I've been in situations where I was sure this was true. I've also been in situations where the person claiming it simply refused to become competent in the language, framework, or persistence technology that the system was built on.
Also subjective: "The business needs a capability the current code was never shaped to grow into." Most of the times I've heard this brought up, it's not that you need a re-write, but you need a re-architecture. Often the existing system can continue to do its job as it always has, but in a new architectural context. Or 90% of the code can stay the same, while the application it runs in is changed, for example from a web service to a Kakfa consumer. (This is why it's so important to avoid languages and frameworks that are tightly bound to an architectural choice.)
> I barely knew CakePHP, so every file looked wrong to me. I knew Laravel, and I loved working in it. So on my own time, unasked, I ported the thing piece by piece, swapping in Illuminate packages until the old framework was gone.
Title is somewhat clickbaity, because these actions are not what people are going to think of when they think of a rewrite in a corporate environment.
By the way, I was an early employee at Amazon.com and the website’s rendering engine was rewritten three times, each time unlocking a new level of productivity without which the site (as well as the velocity of teams) would have slowed to a crawl, and the company would have probably died.
Very rarely have I heard an engineer look at a functioning piece of software and go “let me rewrite this because it’s not a language or framework I am familiar with and fond of”. If that does happen, it’s usually inexperienced (or bad) engineers.
Rewrites usually start with a gap in what is available and what is needed: missing functionality, existing frameworks getting obsolete, difficultly maintaining code because of the existing implementation complexity, costs, scalability issues, compliance challenges, etc. Most of these things serve the business more than the engineers.
If you commit to being around for all the support calls, then do any rewrites you want. But the rewriters unfortunately tend to use it to pad out CVs and move on.
With a title like that you have to back it up. It's a shallow article.
> why it was worth doing, because it wasn't, at least not to the business. The application did the same job for the same users at the same speed as before.
Application have many other properties then "doing their job". Running cost, maintainability, ... it's endless. Any of them going seriously wrong can tank the company owning it.
But I agree, rewrites are very often bad. I've been the customer of two banks that spent years to rewrite their online bank. It was crap and missing features! But maybe they got something out of it.
A rewrite needs to first make business sense and where there is clear ROI. The problem for many companies, is they can get suckered by architecture astronauts and their specific or peculiar tastes, so that they end up just flushing lots of money down the toilet.
And then the architecture astronauts, especially the slick ones, jump ship before people fully recognize or become aware of the new bugs, level of waste, or extent of damage that was done.
Never fix a bug without having first written a red test.
Never just write code. Always write red tests first.
In fact you can do even better and have your agent write end-to-end tests first as acceptance tests, have it witness them fail, then have it do red/green at the unit/component/integration level. Once it’s done the e2e tests pass, have it send the code off for linting and self-review.
If you are vigilant you’ll end up with a trustworthy validation suite. And with that (especially with e2e coverage), you can refactor and rewrite as much as you like.
Yahoo bought Viaweb from Paul Graham and rewrote the Lisp application in C++ and Perl. Reports are the results were strictly inferior but it achieved the goal of not having to rely on Lisp programmers.
Part of Yahoo's business is/was hiring programmers reasonably cheaply and controlling them reasonably easily - to allow Yahoo itself to sell parts or all of itself.
So things aren't quite a simple as "this doesn't serve the product", sometimes the engineers (and their replaceability) are part of the product.
It’s also worth taking a look at the git history of the repo. The current state is an accumulation of scar tissue, but you can see the actual reasons behind some things by figuring out why they were added in the first place.
The article is AI slop, obviously, like practically everything on the internet these days it seems. Awful writing, circling endlessly around the same point. The entire article could have been a single sentence. Which of course, is how it began. As a prompt.
The article is also wrong. Or, at least, indicative of a broken relationship between management and engineering. If you have an engineer who can decide to rewrite the entire product without management buy-in, then that's an organisational and a discipline problem.
Added to which, of course, maintainability and build-ability both matter an enormous amount. Work to improve both of those things will improve the business.
> Most rewrites answer to the engineer - what they want to learn, what offends their taste, what looks good in an interview - and not to the company paying the salary.
One big caveat to this is that a large (and increasing) part of the value of the senior engineering hire is their taste. ‘Taste’ as honed by the software industry approximates business needs that the business doesn't even know it has. Sometimes engineers struggle to articulate ‘why’ a particular change is beneficial because they're just pattern-matching: they've seen the existing pattern break in a dozen different ways in a dozen different codebases, so now when they see the same thing again it ‘offends their taste’ — it looks indefinably wrong even though it doesn't seem to be causing any direct harm right now.
(Of course, sometimes it turns out just to be that they don't understand what's going on, especially but not exclusively for more junior engineers. Pobody's nerfect.)
I've worked in projects where change was expected, so a policy of strict integration testing was introduced - test that treat the system as a black box and aren't aware of its internal structure (to a point, there is always some compromise). Every bug had to have a matching integration test. This made rewrites cheap, boring even (there is always _some_ danger of course, but the approach significantly simplified the decision to rewrite some part of the system or another).
I was hired once to be the Rails guy on a team of competent web developers, that didn't know Rails. I spent two years slowly ironing out issues with the codebase. By the time I was done our velocity had increased to the point to where a two week sprint took three days to complete. They couldn't feed us enough work. We all got pretty good at ping pong.
Until one day our dear team lead rammed a full NodeJS rewrite down our throats.
28 comments
[ 2.4 ms ] story [ 59.0 ms ] threadI mean, if you do it at 4am, you are sleep deprived by the day two and thus unable to stop yourself from something stupid.
you’ll only find out which kind of rewrite you’re doing once you start it.
I've been in situations where I was sure this was true. I've also been in situations where the person claiming it simply refused to become competent in the language, framework, or persistence technology that the system was built on.
Also subjective: "The business needs a capability the current code was never shaped to grow into." Most of the times I've heard this brought up, it's not that you need a re-write, but you need a re-architecture. Often the existing system can continue to do its job as it always has, but in a new architectural context. Or 90% of the code can stay the same, while the application it runs in is changed, for example from a web service to a Kakfa consumer. (This is why it's so important to avoid languages and frameworks that are tightly bound to an architectural choice.)
Title is somewhat clickbaity, because these actions are not what people are going to think of when they think of a rewrite in a corporate environment.
By the way, I was an early employee at Amazon.com and the website’s rendering engine was rewritten three times, each time unlocking a new level of productivity without which the site (as well as the velocity of teams) would have slowed to a crawl, and the company would have probably died.
Rewrites usually start with a gap in what is available and what is needed: missing functionality, existing frameworks getting obsolete, difficultly maintaining code because of the existing implementation complexity, costs, scalability issues, compliance challenges, etc. Most of these things serve the business more than the engineers.
> why it was worth doing, because it wasn't, at least not to the business. The application did the same job for the same users at the same speed as before.
Application have many other properties then "doing their job". Running cost, maintainability, ... it's endless. Any of them going seriously wrong can tank the company owning it.
But I agree, rewrites are very often bad. I've been the customer of two banks that spent years to rewrite their online bank. It was crap and missing features! But maybe they got something out of it.
And then the architecture astronauts, especially the slick ones, jump ship before people fully recognize or become aware of the new bugs, level of waste, or extent of damage that was done.
Never just write code. Always write red tests first.
In fact you can do even better and have your agent write end-to-end tests first as acceptance tests, have it witness them fail, then have it do red/green at the unit/component/integration level. Once it’s done the e2e tests pass, have it send the code off for linting and self-review.
If you are vigilant you’ll end up with a trustworthy validation suite. And with that (especially with e2e coverage), you can refactor and rewrite as much as you like.
Part of Yahoo's business is/was hiring programmers reasonably cheaply and controlling them reasonably easily - to allow Yahoo itself to sell parts or all of itself.
So things aren't quite a simple as "this doesn't serve the product", sometimes the engineers (and their replaceability) are part of the product.
The article is also wrong. Or, at least, indicative of a broken relationship between management and engineering. If you have an engineer who can decide to rewrite the entire product without management buy-in, then that's an organisational and a discipline problem.
Added to which, of course, maintainability and build-ability both matter an enormous amount. Work to improve both of those things will improve the business.
I always do that. I used to assume they knew better than I. I've been wrong a lot about that.
One big caveat to this is that a large (and increasing) part of the value of the senior engineering hire is their taste. ‘Taste’ as honed by the software industry approximates business needs that the business doesn't even know it has. Sometimes engineers struggle to articulate ‘why’ a particular change is beneficial because they're just pattern-matching: they've seen the existing pattern break in a dozen different ways in a dozen different codebases, so now when they see the same thing again it ‘offends their taste’ — it looks indefinably wrong even though it doesn't seem to be causing any direct harm right now.
(Of course, sometimes it turns out just to be that they don't understand what's going on, especially but not exclusively for more junior engineers. Pobody's nerfect.)
Except the Rust rewrites that have been ordered directly by "business"
Until one day our dear team lead rammed a full NodeJS rewrite down our throats.