Use boring tech.

That's a good mantra. When you're stacking your Jenga tower, it's probably a good idea not to have your pieces of blocks in funny exciting shapes.

As a person building and keeping an infrastructure running, keepin' in boring gives me a pass at not chasing shiny techs.

But I smell a hint of complacency. Boring works if all you care is that your product runs.

If you aim loftier than just running; you care that it endures, then this starts being questionable.

See, boring eventually leads to fossilization. That's what I've been contending with recently about my 8 year-old monolithic Django-oriented architecture.

As it is, it's running fine in a good-enough manner. It will probably run fine in the next eight years.

But as soon as anyone tries to upgrade any item in the stack, it ends up forcing a slew of dependency upgrades, vertically and horizontally. Essentially nothing can be upgraded in isolation, it's a wholesale change or nothing. Under such condition, something is bound to break.

Now multiply that by the amount of upgrade cycles it takes to chase up to the most recent version.

That leads me to conclude that modernizing my monolithic stack is practically impossible. At least not at the cost that I'm willing to pay.

A large enough monolith creates substantial inter-package dependencies.

Dependency-hell get in the way of upgrades.

"But so what?" you may say. Implicitly I'm saying that lack of upgrades actively discourages new developers from wanting to work on the system. Lack of new blood slowly and surely guarantees the death of a product.

This is an unproven point. But it makes intuitive sense. It's not what we hope what the world is, it's world we have (if it's true).

The parallel to socioeconomy is uncanny.

Dependencies in a system actively prevents new languages and methodologies.

A suite of packages running on Python 3.6 would have a risky time being run asked to run on Python 3.12.

A chip exporter would have a hard time being asked to trade using gold when they've been using US dollar for decades.

A family switching verbal language among themselves is downright impossible.

A network of dependencies keeps the status quo intact, impenetrable to new languages/methodologies/ideas.

My thesis pushes it quite far: old stacks prevent new blood, effectively fossilizes.

That's not immediately obvious. Why can't young people learn old systems? Aren't we all using human languages that are thousands of years old?

Even in human realm, languages shift among generations. Accents, slangs, dialects develop. No one sounds like FDR today, and no one is demanded to be so. Similarly I wouldn't demand a coder 32 years from now to operate a model-controller-view framework if there's something clearly superior.

Fashion and languages accelerate in software realm. If human protocols evolve at the same rate, we won't even be speaking English by now.

While there do exist categories of software that can reach the status of done, most user-facing software are never done, only abandoned.

So how do you modernize something that can't be upgraded? The answer I've reached rhymes with microservices, but I prefer the phrase decomposition.

Essentially that means breaking a large machine into smaller pieces of autonomous machines. If the large machine is a giant tanker, decomposition would mean turning it into an armada of small boats.

They are autonomous in the sense that they are free to run in any stack they want without affecting anybody else. This is the quality that allows for modernization.

The equivalent concept in politics would be special economic zones, like Shenzhen. A system like this would be a federation of Shenzhens, each one free to enact their own sets of regulations.

In the long run, this is the proven way to run a dynamic society. And likely that's the way to keep a software alive.

A monolith is akin to a centrally planned economy. That works for endurance only if it's small and nimble enough.

The line for that isn't clear. It took a long time for me to see that I've crossed it.