To Special Economic Zones, From Monolithic Software

Monoliths are anti-innovation in at least three ways:

1. You’re required to comply with existing norms and technical consistency infra, limiting options

2. Your changes might impact others, so peer review processes are added, increasing time to change

3. Monoliths are big, so there’s a larger onboarding cost. This is like a learning curve constraint, distinct from (1) which is a constraint on the space of implementations and even values (process X is slower but cheaper, the monolith team has enshrined it as preferred)

Now consider the nation state as a monolith.

How do we innovate?

Breaking apart a monolith is an option and many try but it is often slow and impractical.

The practical solution is to carve out a subframework that enables your team to do things it cares about quickly within the larger monolith. You get a bunch of exceptions over time and eventually it feels mostly like your own framework of choice. Admittedly that’s not formally true from first principles but it’s practically very close to true.

And you opportunistically launch green field going forward when it makes sense. But you largely avoid refactoring the legacy code.

And that’s why Special Economic Zones, Charter Cities, and similar reforms are much more practical than devolution, secession, revolution, and other major separatist movements.

Plus they scale better and in particular they scale *down* better which means you need less money, space, and people to affect change and you also raise fewer eyebrows when you do.

Many such things by various names will succeed over time in significant legal reform over many locations.