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.
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.
Rewrites are like heavy power tools - they are dangerous, but they can do great things when used right.
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
Jeffrey dot Sherman at gmail
Would truly love to hear about your experience
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.
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.
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.
Even when the technical parts happen to be better, there are often politics involved when the new systems imply changing the way people work.
Honestly, this approach worked well for me in the past.
Did rewrite parts of an vb6 application in .net really was a Frankenstein monster.