5 ms·

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" c

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.
- greatpostman 3y ago
  All of my best work has been done this way. Most jobs won’t allow it, but really good software managers will
fendy3002 3y ago
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.
BizarroLand 3y ago
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.

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.

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

fendy3002 3y ago

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.

BizarroLand 3y ago

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.