I gotta say, I sympathize with their "goes against every instinct" plight. If I had joined a team 2 months ago, and they'd been working on something for a year, and I was thinking "we should scrap this and start it over from scratch," I'd be really, really suspicious of my own thinking. Scrap and start over is such a tantalizing programmer thought for something that seems complicated and broken, and you'll almost always want to do it, and it's almost always the wrong call. Glad it was the right call here.
You see both sides of the coin often-- people are often too quick to go for a rewrite. But then you also often see the "rewrites are almost never a good idea" camp that dismisses the benefits too quickly.
The reality is rewrites are often appropriate but they need to:
1. Have a clear tangible benefit (or ideally many benefits)
2. Be as tightly scoped as possible to achieve the above benefits. Rewriting everything at once is a horrible idea in all but the most egregious cases.
3. Be as incrementalized as possible.
The best systems I've created came from iteratively experimenting with the language / API / whatever. Build something for the sake of learning, throw it away, build another experiment to learn, throw it away, take a shot at the real thing, throw it away, etc. It starts to feel like if you rewrite and think about the problem enough you'll eventually reach a point where you can write or rewrite the whole system in a week. Which leads me to conclude:
Systems that can be rewritten should not be rewritten. Systems that cannot be rewritten should be rewritten.
It's not quite true (not in all circumstances), but it's close. I think most enterprise / pile-of-business-rules software falls into the latter category, those systems cannot be rewritten, but they should be.
Expanding on your first criteria. The technology stack is fundamentally wrong is a good reason for a re-write. Language too slow. Doesn't handle the workload well. Other stacks have a better ecosystem.
Re-writes are also needed when the architecture doesn't match the problem space well. This can be incrementally done. Single threaded loops instead of using parallel-safe constructs like tasks and jobs.
Spot on. Inexperienced people want to rewrite because they may not know the problem domain. Experienced people do rewrite because they know what they want to achieve.
And there's many ways to rewrite and migration strategy other than full rewrite.
A rewrite makes sense for two reasons. 1: No two people on your team understand the code from start to finish, or 2: (as in this case) the current stack cannot perform to the standards required, and another stack can.
Too many people just want to remix code or rehome it, taking the papers out of the old book and putting them into a new cover. At the very least, take the time to make sure you fully understand the system before you replace it.
Was it though? I mean, the goal was SSR, but if they had a fully functioning site sans SSR, why not ship now, then deploy SSR whenever it gets baked into Angular?
They were using Angular's dependency block them when I don't think they really needed to be blocked to ship a product.
> The relaunch of our ecommerce website had one goal: deliver blazing fast performance with Server-Side Rendering.
you’re suggesting they ship a rewrite that doesn’t do the one thing they’re rewriting for? at the time they also didn’t know when ssr support would be available.
they switched and shipped ssr support faster than it would have been available otherwise.
This is so bad. The worst of us all, but fun to read about the brinksmanship. The worst line for me was:
“From the founders' perspective, they had a clear stop-loss in place if things didn't work out” with the “stop-loss” being that “[t]he React site would be functional and performant in 6 weeks, and ship in 10. If it didn't, I would step down and recruit a replacement.” It’s just such a horrible thing to put on people, and is in no way a real stop loss.
So things failed, and now we lost our chief engineer, and who knows if they will “recruit a replacement” when they are either gone or on their way out, and recruiting leadership can take so long it’s such a crapshoot. THAT is a “clear stop-loss” to this person? Big oof.
It’s just such bad framing and bad ultimatums and bad people all around that I feel like I’m watching trash tv — and I love it.
Author here. It was a gamble, but I was fighting against a very strong sunk cost fallacy in leadership at the company at the time, and there was a general lack of trust in the entire technical team. I *would not* recommend this approach as a typical way of doing business, and maybe I didn’t do a good enough job at communicating that in the post. This is the only time in my career I’ve delivered this kind of ultimatum.
Everything about this particular situation was exceptional. I focused on the decision to do a rewrite in the post because I thought it was the more interesting part of the story. In hindsight I might have gotten that wrong.
I don't think it's really that wrong-headed. What are the choices: (1) march ahead trying to salvage the current design with no clear path forward (other than waiting for the SSR solution), (2) quit right now, or (3) quit in 6-8 weeks if the proposed solution doesn't work (or is not delivered fast enough). The last option is not that bad if the author is hoping to figure it out, especially that the timeline is short and with a quick prototype (which the author did) it's going to be clear much sooner if the new approach is workable or not.
That was the most ridiculous part. So in 10 weeks you would have no Angular site. You would potentially have no React site. You would lose your engineering lead. And the management signed off on this suicide pact?
By how the article is written it sounds like the ultimatum was the author's idea, as their way of securing the founders' buy-in. The ultimatum wasn't the stop-loss, it was the fact that the Angular project would ship if the angular team shipped SSR.
I think the primary reason the management team went along with the re-write is the thing that they had been struggling on for months could be working well in 6 weeks and complete in 10. This must have been a pretty small project - but kudos to the author and team for pulling it off.
To be fair the original also had a 12 week projection. So this 10 week 'estimate' was at that point just that. From a management point of view I would read this as an implicit 'we do this or I quit now'.
While the 168mb is ridiculous, I'm more facinated by the choice to depend on an unimplemented feature from a group/company they had no control over or contracts with. I would hesitate to depend on things which haven't been released for a few months/years.
I realize the web moves fast and some might prefer working with new technology, but this sounds so weird to me.
I’m really curious what this article would look like if it was written from the perspective of one of the “boots on the ground” developers that spent 8 months on the original PoC, rewrote it in the 7 weeks, and is still maintaining it today.
Other commenters here are focusing on the bundle size or the choice of framework, but I'm really surprised by the stack: It's an ecommerce app, why do you need a SPA for it? I really think people have just forgotten how quick and easy it was to write SSR code that has a bit of interactivity on the frontend as-needed, and has gone full in on SPA all the things.
I wonder how long it would have taken them to write with plain HTML served by simple views.
Yeah, I did get a bit dismayed at "so we rewrote it and kept all the complexity, but used a framework that had the critical feature the old one didn't".
Sometimes I think the best thing an eCommerce Company could do is move their home-rolled eCommerce app to Shopify / BigCommerce / some other eCommerce SaaS. I imagine that 8 months of getting to know a true eCommerce platform and purpose-building plugins would result in a pretty reliable eCommerce app. Especially if you never have to worry about if your Cart, Check-Out page, or PayPal/Google Pay/Apple Pay plugin is going to break on every update.
> *"We delivered the new version of the site after 7 weeks"
I know everyone is focusing on 168MB, but ...
The bigger issue that needs to be addressed for this leader is - why did the previous project take 10-months, when that same team was able to deliver an entirely new rewrite version in just 7-weeks (without all the code bloat as well).
a large part of why it took 7 weeks was the work they had done over the last 10 months to gather requirements and translate them to code. the exact form of the code is merely the last stage in the process - i wager it would have taken them considerably longer than 7 weeks if they were starting the react site from scratch.
you are certainly correct. But there is a sentence that stood out to me, one where he said that devs needed to wait up to a minute to see their changes. I’ve personally felt the slog of writing code that takes easily 2 minutes to see changes, compile, flash unit, connect via bluetooth see if change shows what’s expected in some blackbox app. It’s maddening, and slows things way down, trying to keep the thought of what you were trying to do for that long is difficult and leads to lots of wasted tests. I largely suspect it’s an exponential function and the longer the feedback the exponentially longer the code takes to write.
1 minute is a long time, and I could see if you could get that loop under 10 seconds you could shave off months of dev time. Hell, I just recently changed a test timeout I was working with from 2 seconds to 1 second, and my morale improved in ways that surprised me even knowing all this.
Its not surprising honestly. There's a point in a codebase's life where it grows to this size that's hard to put all the moving parts into your head. Bloated, corrupted, every change takes careful caution to make sure it doesn't affect some other part downstream. You might know certain parts are not optimal or efficient, but you don't have the time to stop iterating on other tasks and fix these inefficiencies, let alone revise all the other built on parts that depend on this sub optimal component.
A clean slate on the other hand is a lot easier. There's no vestigial pieces. No dependencies on hastily written functions you never got the time to rewrite the right way. You aren't locked into some version of a library from three years ago, you can use all the latest tooling.The shorter the codebase is in total, the easier it is to grasp the scope of how it all works together and move faster, knowing where other things should fit in a much simpler mental model.
In fairness, rewrites can be quite a bit faster than an earlier incarnation. By that point you've identified key gotchas, can simplify quite a few things, etc.
I don’t have much experience with frontend frameworks / libraries, but I really dislike the way this article presents React as the silver bullet.
Maybe it is factually accurate that Angular was the wrong choice for e-commerce (at the time?). I don’t know. Without SSR, was there really nothing feasible they could do to reduce the page load time? Did Angular make tradeoffs that are better for a large, interactive web application; and you want a different set of tradeoffs for ecomm use cases? Or were they just stuck with the wrong tech at the wrong time: complicated enough that it’s too slow in Angular, and the project hadn’t caught up to them yet?
That JS bundle was doing _something_ (probably lots of somethings). How many features did the React rewrite drop? Could you have removed those features from the old codebase, or would that have been politically infeasible at the company? (“no, don’t delete that” vs “yeah, we can live without that, you don’t need to implement it” -> author gets to add a Loss Aversion sidebar). Are there still items in the backlog to re-implement missing features (that the team intends to complete)?
Development effort compared between stop-the-world rewrites (in order to hit their 7 week “really big shopping event”) vs rewrite following ongoing feature development and the painful merges mentioned in the article. Obviously business appetite changed for a stop-the-world rewrite, but could that have been identified earlier?
Changing requirements: did the Angular upgrade start with “we need SSR” as a top requirement? It seems more likely that there were a bunch of benefits / requirements for a technology upgrade, and over the previous 10 months they’d discovered SSR as a blocker. Erasing the other improvements makes the 10 months vs 7 weeks sound very impressive, but seems disingenuous.
Maybe my expectations are off for a blog post format.
> I really dislike the way this article presents React as the silver bullet.
It didn't read like that to me, I thought the point was they went for a rewrite on the new breaking changes major version, expecting specific features to eventually land, were waiting for them, and React had them already.
So it's more (to me) like 1) don't do that; 2) if you're going to do that maybe take a step back and there's something else out there already or that's a better fit.
It could have been any technology. The silver bullet is choosing the right tool for the job.
I don’t have an attachment to any particular tech. At the time React was what I knew, and I was coming off the back of building a server side rendered React site when I joined this company. I had a team of JavaScript-focused engineers to work with.
Readit News
The reality is rewrites are often appropriate but they need to: 1. Have a clear tangible benefit (or ideally many benefits) 2. Be as tightly scoped as possible to achieve the above benefits. Rewriting everything at once is a horrible idea in all but the most egregious cases. 3. Be as incrementalized as possible.
Systems that can be rewritten should not be rewritten. Systems that cannot be rewritten should be rewritten.
It's not quite true (not in all circumstances), but it's close. I think most enterprise / pile-of-business-rules software falls into the latter category, those systems cannot be rewritten, but they should be.
Re-writes are also needed when the architecture doesn't match the problem space well. This can be incrementally done. Single threaded loops instead of using parallel-safe constructs like tasks and jobs.
And there's many ways to rewrite and migration strategy other than full rewrite.
Too many people just want to remix code or rehome it, taking the papers out of the old book and putting them into a new cover. At the very least, take the time to make sure you fully understand the system before you replace it.
Actually read the source code before a rewrite.
That they gave the project another two months is another important part of the experience.
So the specific project was clearly a failure. They weren't talking about rewriting working code, let alone code that was making money.
To me, it looks like it took a lot to violate the never-start-over-prime-directive-for-progress in creative work.
They were using Angular's dependency block them when I don't think they really needed to be blocked to ship a product.
> The relaunch of our ecommerce website had one goal: deliver blazing fast performance with Server-Side Rendering.
you’re suggesting they ship a rewrite that doesn’t do the one thing they’re rewriting for? at the time they also didn’t know when ssr support would be available.
they switched and shipped ssr support faster than it would have been available otherwise.
“From the founders' perspective, they had a clear stop-loss in place if things didn't work out” with the “stop-loss” being that “[t]he React site would be functional and performant in 6 weeks, and ship in 10. If it didn't, I would step down and recruit a replacement.” It’s just such a horrible thing to put on people, and is in no way a real stop loss.
So things failed, and now we lost our chief engineer, and who knows if they will “recruit a replacement” when they are either gone or on their way out, and recruiting leadership can take so long it’s such a crapshoot. THAT is a “clear stop-loss” to this person? Big oof.
It’s just such bad framing and bad ultimatums and bad people all around that I feel like I’m watching trash tv — and I love it.
Or least, that's what I would think as a manger.
"Wow, you're serious. I believe (a) you're sincere in what you're telling me and (b) you are going to do everything this takes to make it a success."
I'll hook my wagon to that.
The statement is wrong-headed in so many ways it invalided anything the author could possibly say after.
Everything about this particular situation was exceptional. I focused on the decision to do a rewrite in the post because I thought it was the more interesting part of the story. In hindsight I might have gotten that wrong.
that's pretty silly. you can be wrong in some areas while still having good insights in others.
Deleted Comment
I wonder how long it would have taken them to write with plain HTML served by simple views.
I know everyone is focusing on 168MB, but ...
The bigger issue that needs to be addressed for this leader is - why did the previous project take 10-months, when that same team was able to deliver an entirely new rewrite version in just 7-weeks (without all the code bloat as well).
1 minute is a long time, and I could see if you could get that loop under 10 seconds you could shave off months of dev time. Hell, I just recently changed a test timeout I was working with from 2 seconds to 1 second, and my morale improved in ways that surprised me even knowing all this.
A clean slate on the other hand is a lot easier. There's no vestigial pieces. No dependencies on hastily written functions you never got the time to rewrite the right way. You aren't locked into some version of a library from three years ago, you can use all the latest tooling.The shorter the codebase is in total, the easier it is to grasp the scope of how it all works together and move faster, knowing where other things should fit in a much simpler mental model.
That is an utterly moronic decision.
I find this comment by user "Dad" very endearing.
Maybe it is factually accurate that Angular was the wrong choice for e-commerce (at the time?). I don’t know. Without SSR, was there really nothing feasible they could do to reduce the page load time? Did Angular make tradeoffs that are better for a large, interactive web application; and you want a different set of tradeoffs for ecomm use cases? Or were they just stuck with the wrong tech at the wrong time: complicated enough that it’s too slow in Angular, and the project hadn’t caught up to them yet?
That JS bundle was doing _something_ (probably lots of somethings). How many features did the React rewrite drop? Could you have removed those features from the old codebase, or would that have been politically infeasible at the company? (“no, don’t delete that” vs “yeah, we can live without that, you don’t need to implement it” -> author gets to add a Loss Aversion sidebar). Are there still items in the backlog to re-implement missing features (that the team intends to complete)?
Development effort compared between stop-the-world rewrites (in order to hit their 7 week “really big shopping event”) vs rewrite following ongoing feature development and the painful merges mentioned in the article. Obviously business appetite changed for a stop-the-world rewrite, but could that have been identified earlier?
Changing requirements: did the Angular upgrade start with “we need SSR” as a top requirement? It seems more likely that there were a bunch of benefits / requirements for a technology upgrade, and over the previous 10 months they’d discovered SSR as a blocker. Erasing the other improvements makes the 10 months vs 7 weeks sound very impressive, but seems disingenuous.
Maybe my expectations are off for a blog post format.
It didn't read like that to me, I thought the point was they went for a rewrite on the new breaking changes major version, expecting specific features to eventually land, were waiting for them, and React had them already.
So it's more (to me) like 1) don't do that; 2) if you're going to do that maybe take a step back and there's something else out there already or that's a better fit.
It could have been any technology. The silver bullet is choosing the right tool for the job.
I don’t have an attachment to any particular tech. At the time React was what I knew, and I was coming off the back of building a server side rendered React site when I joined this company. I had a team of JavaScript-focused engineers to work with.