5 ms·

The only fun part about re-writes are the days we spend fantasizing about how much better it will be, that's it. Don't do a re-write kids, but if you do, do it

The only fun part about re-writes are the days we spend fantasizing about how much better it will be, that's it. Don't do a re-write kids, but if you do, do it from within the existing software like a parasite or a chest bursting creature from the movie Aliens. Either way it always be messy, terrifying and most of the time ends in tragedy.

deleted 3y ago
[deleted]
zmgsabst 3y ago
This is where the derivative of the facade pattern comes from: The smother pattern. Where you write a facade, then replace calls iteratively with the rewrite until you’ve removed all the calls to the old API. Then you turn it off. Sometimes rewrites are genuinely a good idea, eg, you’ve lifted-and-shifted a service but would like to better integrate with cloud services.
hinkley 3y ago
The other fun thing is that management tends to give you benefit of the doubt for the first six months give or take. They don’t know it’s a boondoggle yet that you will eventually come to regret almost as much as the original (and which they will regret more). This realization dawns slowly enough for most people that they mistake it for a desire to move on to another project. A certain number of the guilty parties will have moved on before the bill comes due.
j45 3y ago
Rerouted are definitely more work than usually anticipated, unless most or all of the original team is available. The other option to figure it out again from scratch has its own issues. If existing business logic works and has been hardened, it can be worth looking at wrapping it an API instead of rewriting and reimagining from scratch.
pinkgolem 3y ago
>Don't do a re-write kids, but if you do, do it from within the existing software like a parasite or a chest bursting creature from the movie Aliens. Honestly, this approach worked well for me in the past. Did rewrite parts of an vb6 application in .net really was a Frankenstein monster.
majikandy 3y ago
Love the parasite analogy, to add to it, it perhaps morphs into a symbiotic relationship between them for a while, with the parasite eventually becoming the host and the original app becoming the parasite that is gradually getting smaller and smaller but you just can’t shift, and the finally one day you clean out that final piece and it feels great. Meanwhile the business got all the new features they wanted when they wanted them and it kept moving forwards at all times.
graypegg 3y ago
Yep. I think the biggest source of "we could make this so much better!" re-writes I've seen in my career is in-house design system libraries. Just a big library of button styles and such. I've personally been responsible for 3 massive failures over 2 companies on that front in the past, and the place I'm working at now actually has a 3rd-order design system rewrite. (An old library that's considered legacy and is still used, a replacement that covers maybe 80% of that API surface with "newer stuff" and is used in some places alongside the old library, and now we're making a new-new library to "replace" those two, but will ultimately live along side them.) Maybe I'm just getting jaded but I'm 100% on board for "just never rewrite". It's almost always a money pit to start fresh, but it's pitched to management as a time save or efficiency move.
glimshe 3y ago
I've led 2 major rewrites, both of them extremely successful, replacing slow and unmaintainable systems by fast and extensible ones (and they have been extended well beyond the capabilities of the original systems). Rewrites are like heavy power tools - they are dangerous, but they can do great things when used right.
- jeffrey-sherman 3y ago
  I’d love to hear more about your experiences! I’m the author of the post and co-host of the never rewrite podcast. Last episode we discussed Khan Academy’s 3.5 year rewrite. https://youtu.be/LqAkIkNs1Ws?si=d3y6J2C6Q3T8qTyF https://youtu.be/LqAkIkNs1Ws?si=d3y6J2C6Q3T8qTyF Jeffrey dot Sherman at gmail Would truly love to hear about your experience
pjmlp 3y ago
I have been part of two rewrite projects, that took a couple of years, and in the end they were thrown away while the original one kept going on. Even when the technical parts happen to be better, there are often politics involved when the new systems imply changing the way people work.

deleted 3y ago

[deleted]

zmgsabst 3y ago

This is where the derivative of the facade pattern comes from: The smother pattern. Where you write a facade, then replace calls iteratively with the rewrite until you’ve removed all the calls to the old API. Then you turn it off. Sometimes rewrites are genuinely a good idea, eg, you’ve lifted-and-shifted a service but would like to better integrate with cloud services.

hinkley 3y ago

The other fun thing is that management tends to give you benefit of the doubt for the first six months give or take. They don’t know it’s a boondoggle yet that you will eventually come to regret almost as much as the original (and which they will regret more). This realization dawns slowly enough for most people that they mistake it for a desire to move on to another project. A certain number of the guilty parties will have moved on before the bill comes due.

j45 3y ago

Rerouted are definitely more work than usually anticipated, unless most or all of the original team is available. The other option to figure it out again from scratch has its own issues. If existing business logic works and has been hardened, it can be worth looking at wrapping it an API instead of rewriting and reimagining from scratch.

pinkgolem 3y ago

>Don't do a re-write kids, but if you do, do it from within the existing software like a parasite or a chest bursting creature from the movie Aliens. Honestly, this approach worked well for me in the past. Did rewrite parts of an vb6 application in .net really was a Frankenstein monster.

majikandy 3y ago

Love the parasite analogy, to add to it, it perhaps morphs into a symbiotic relationship between them for a while, with the parasite eventually becoming the host and the original app becoming the parasite that is gradually getting smaller and smaller but you just can’t shift, and the finally one day you clean out that final piece and it feels great. Meanwhile the business got all the new features they wanted when they wanted them and it kept moving forwards at all times.

graypegg 3y ago

Yep. I think the biggest source of "we could make this so much better!" re-writes I've seen in my career is in-house design system libraries. Just a big library of button styles and such. I've personally been responsible for 3 massive failures over 2 companies on that front in the past, and the place I'm working at now actually has a 3rd-order design system rewrite. (An old library that's considered legacy and is still used, a replacement that covers maybe 80% of that API surface with "newer stuff" and is used in some places alongside the old library, and now we're making a new-new library to "replace" those two, but will ultimately live along side them.) Maybe I'm just getting jaded but I'm 100% on board for "just never rewrite". It's almost always a money pit to start fresh, but it's pitched to management as a time save or efficiency move.

glimshe 3y ago

I've led 2 major rewrites, both of them extremely successful, replacing slow and unmaintainable systems by fast and extensible ones (and they have been extended well beyond the capabilities of the original systems). Rewrites are like heavy power tools - they are dangerous, but they can do great things when used right.

jeffrey-sherman 3y ago
I’d love to hear more about your experiences! I’m the author of the post and co-host of the never rewrite podcast. Last episode we discussed Khan Academy’s 3.5 year rewrite. https://youtu.be/LqAkIkNs1Ws?si=d3y6J2C6Q3T8qTyF https://youtu.be/LqAkIkNs1Ws?si=d3y6J2C6Q3T8qTyF Jeffrey dot Sherman at gmail Would truly love to hear about your experience

pjmlp 3y ago

I have been part of two rewrite projects, that took a couple of years, and in the end they were thrown away while the original one kept going on. Even when the technical parts happen to be better, there are often politics involved when the new systems imply changing the way people work.