This is the sombrer branch of a dystopian choose-your-own-adventure essay on systemic failures to carry through sizeable projects in "enterprise" environments.
Its alternative write-up is found at: A systemic failure to follow through.
Suppose that we have a problem.
Suppose that our e-commerce Web app consists essentially of a patchwork of legacy "enterprise" Java front-and-back–end powered by Apache Wicket (popular 2007–2012), Apache Struts (2002–2007), Apache Tapestry (2004–2007), or all of the above, and we never quite considered ever serving customers on mobile devices.
Or suppose any sort of system deeply entangled with everything, including itself, some sort of living root bridge, except it's a whole treetop dwelling, nothing but intertwined roots as far as the eye can see, a gnarled knitting of Gordian knots that started out as a decision never formally taken and grew into a institutionalised way of life.
Well, it's 2025 now, and it turns out that while the IT department never considered smartphones, tablets (or the fact that windows aren't always maximised, and on a horizontal monitor with the default font size and zoom factor), our customer service department did... Where do they get their ideas from, eh?
The time comes to reinvent the entire thing. We go for whatever is trendy and must therefore be the best in all regards, React. Well, not just that, of course: we probably need a hefty dose of other frameworks (Nx maybe?) on top, for greater simplicity; then some bespoke abstractions to avoid everybody having to learn the underlying tools.
None of the parties responsible for the decisions have both a serious, foundational understanding of building the Web in the first place, as well as significant experience maintaining a corporate-scale application to boot, yet they still managed to land on the one panacea that contemporarily solves all problems: obviously, it is that simple; we're off to the races.
We create tools to run the tools to operate the transpilers, bundlers, minifiers, linters, formatters (et caetera); we create tools to facilitate the usage of the tools to version-control our code. Name your micro-task, we are building some specialised (read: contrived) mean to do it some sort of way.
Soon enough, everything is ready, 90% of the job is done and all that remains is to migrate/adapt/rewrite everybody to El Dorado.
Now, onto the remaining 90% of the job (ha!): integrating the solution.
Every now and again we advocate for the new platform, but each team is responsible for bringing their piece of the puzzle up to date, on their own time: the feature requests for the established solution are still pouring in. Yet the curators of its modernised counterpart aren't left idle, there is much thumb-twiddling in the works:
We establish ADRs, we keep expanding the procedures and making things yet simpler by identifying patterns and systematically preventing anybody from having to endure how the sausage is made: do not repeat yourself—or anybody else, consistency is the opiate of the sophisticated mind, this project is so DRY it could pass for a British comedy.
We struggle to bring the two worlds to parity. In fact, we're nowhere near: we have to start actually using it in its current state. We can offer customers (maybe the new ones?) to use that version while ensuring that the Old Faithful still avails itself our clientele deserving of the same epithet.
To help promote the new platform, we started building (on rare occasions, of course) some features only there. We figure that the most adequate way to forcefully dedicate all our resources to the migration effort is indeed to corner ourselves in a situation where there is strong, business-driven demand for it.
Some teams decide to opt for the Strangler Fig Pattern, some attempt to Branch by Abstraction, some plan to just do it. Advancement is sporadic, as it turns out that quite a few bits and bobs depend on other odds and sods, and a few whatchamacallits are tangled up with some stray thingamajigs.
Customers of either solution are overall somewhat satisfied with the experience, but the whole IT department has somehow ground itself to a halt, for which an innocuous explanation ends up becoming quite a gloomy revelation: we do maintain two separate solutions, after all.
In a bitterly ironic twist of fate only Randall Munroe could have foreseen, we are starting to consider that maybe the Second System (yes, we actually call it that) isn't the way to go. It lacks features, isn't widely adopted, and still demands much upkeep.
Suppose that we had a problem... Now we have two.