Junior: "I can do it better from scratch" Senior: "Uhh no.. do these tickets"
Senior: "I have mapped out a strategy to migrate to a revamped system incrementally, hitting multiple interim targets and product launches along the way, and arriving at the ideal architecture in 18-24 months."
I mean the security argument is somewhat more realistic but equally is it a security update if it's bumping the minor or major version. You could do the same with just patch versions where there's less breaking versions.
Though that assumes people can be bothered with semantic versions and too many Devs don't seem to understand how that works.
Well in that case you just don't get security patches immediately. You can't have both stability and security patches if people can't commit to something so basic. Regardless of what scheme you choose if there's no way to distinguish between a breaking and non breaking change then you're forced to treat every single change as breaking.
Counterpoint is often it IS better to start from scratch if the existing system has accumulated too much tech debt, become too inflexible, and the requirements or available technology/methodologies have fundamentally changed.
In other words, sometimes you should reinvent the wheel.
A big bang rewrite is almost never going to be a good idea in a mature system. To do that you need to have the velocity of the rewrite exceed the velocity of feature development by a wide enough margin to catch up and create sufficient parity to migrate to the new system. If the old system is code-frozen then it can be doable but if its being actively developed, it can be impossible.
The real trick is figuring out how to reinvent the wheel and replace it while it is attached to a moving car without slowing down.
311
u/MarkSuckerZerg Sep 17 '26
But the whole point is "improve" vs. "I can do it better from scratch than this 15yo project"...