Hacker News Reader

Comment by CobrastanJorji | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

All of my best work has been done this way. Most jobs won’t allow it, but really good software managers will

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.

Actually read the source code before a rewrite.

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.

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.

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.

Reply on news.ycombinator.com