5 ms·

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,

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.

dabbz 3y ago
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.
- notnmeyer 3y ago
  it was the right call. > 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.
alfalfasprout 3y ago
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.
- yxre 3y ago
  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.
  - bruce511 3y ago
    Expanding on your point, rewrites can work if they can be accomplished in finite time. It's one thing to rewrite a website, where the project timeline is measured in weeks. It's another to rewrite large project where the -estimate- time is years. We have mature desktop systems that have been in continuous development for 25 years. That might blow your mind, but its the same timescale as say Excel of Word. The question of rewriting, regardless of the tech stack, is moot. It would take years of effort (optimists think 5, more likely 10) and would cost a fortune. With negligible benefits beyond "now written in a language with a bigger developer pool". I'm the first to admit that there are disadvantages to the stack. On the other hand we are where we are (doing well) thanks to that stack, so it's not all bad. We're still using code laid down in 1996, while being a modern desktop app. We're still the leaders in our field. The time (aka cost) to rewrite is the major hindrance, and far outweighs any issues using an uncommon stack.
- Buttons840 3y ago
  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.
brudgers 3y ago
That the project was supposed to ship in three months is an important part of the author's specific experience. 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.

dabbz 3y ago

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.

notnmeyer 3y ago
it was the right call. > 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.

alfalfasprout 3y ago

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.

yxre 3y ago
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.
- bruce511 3y ago
  Expanding on your point, rewrites can work if they can be accomplished in finite time. It's one thing to rewrite a website, where the project timeline is measured in weeks. It's another to rewrite large project where the -estimate- time is years. We have mature desktop systems that have been in continuous development for 25 years. That might blow your mind, but its the same timescale as say Excel of Word. The question of rewriting, regardless of the tech stack, is moot. It would take years of effort (optimists think 5, more likely 10) and would cost a fortune. With negligible benefits beyond "now written in a language with a bigger developer pool". I'm the first to admit that there are disadvantages to the stack. On the other hand we are where we are (doing well) thanks to that stack, so it's not all bad. We're still using code laid down in 1996, while being a modern desktop app. We're still the leaders in our field. The time (aka cost) to rewrite is the major hindrance, and far outweighs any issues using an uncommon stack.
Buttons840 3y ago
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.

brudgers 3y ago

That the project was supposed to ship in three months is an important part of the author's specific experience. 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.