Sure, though having gone through an entire monorepo refactoring of like half a million lines to basically destroy the codebase and switch from vue 2 to vue 3 among other things, it’s also possible to build the new, better designed wall right behind the old one, test like hell against that wall, and then shift that wall in when it’s ready in a planned release, ready for the issues that come because that wall isn’t quite like the old wall
* For a very specific value of “works”. Offer is limited in time. No refunds. Warranty doesn’t cover damage caused by the elements, presence, or lack of gravity. Other conditions may apply.
Your options are an ugly wall that works or the beautiful lack of a wall.
Sure, though having gone through an entire monorepo refactoring of like half a million lines to basically destroy the codebase and switch from vue 2 to vue 3 among other things, it’s also possible to build the new, better designed wall right behind the old one, test like hell against that wall, and then shift that wall in when it’s ready in a planned release, ready for the issues that come because that wall isn’t quite like the old wall
This is a dangerous metaphor. Remove the old wall and it turns out the new beautiful wall was leaning against and supported by it.
I get what you mean, it’s just that the metaphor could support both perspectives.
Build the new wall airgapped from the old one
And keep both walls for redundancy.
Ah, yes: weaponizing cybersecurity requirements to trick - I mean “motivate” - higher management to do things “right.”
* For a very specific value of “works”. Offer is limited in time. No refunds. Warranty doesn’t cover damage caused by the elements, presence, or lack of gravity. Other conditions may apply.