You don’t need to remove complexity, you need to abstract it gradually.

Complexity is there for a reason. Someone built that complexity to solve an ugly, complex underlying problem. There’s a book/post somewhere about how “everyone wants to rewrite stuff to make it simpler, ignoring that the current project also started out simple!” — (I don’t know the name, please point me to it and I will include the reference here.)

Engineers often have the instinct to KILL complexity, to REWRITE complexity away or to DEPRECATE it. Consider these might be either ineffective or inefficient. You’ll have to create a new solution from scratch. It will look great in the beginning. Until it meets users and their real-world ever-changing needs.

You might consider, instead, to allow for complexity and hide it away. Create a new layer of abstraction where the complex stuff is but a kernel, a low-level implementation detail allowing for richer expression on top, and at the sides. Users can choose the new solution gradually, at their pace.

Allowing people to continue using their interfaces will improve adoption of a new infrastructure. Being compatible helps early users adhere without friction or disruption, while also providing valuable feedback. It’s literally lowering the barrier of entry to your ecosystem.

Therefore, I invite you to stop treating your legacy system/platform/technology as something you need to kill, something which threatens you. What you resist, persists: this will only make it more painful to work with it. There is a way out of this war: being compatible.

Respect your past for getting you here, and create the possibility for new users to slowly try new solutions, instead of requiring a big-bang switch. This strategy is absolutely simple, yet very hard to do. (I suspect that’s why most teams end up pressured to choose the latter.)

Case in point: props to the Deno language for going in the direction of --compat which will allow very useful node tooling like rollup to be first-class citizens of the Deno ecosystem. And props to the Builder.io team for working on Mitosis, allowing you to write one component and use it in any stack. These examples are the power of compatibility at its best.

Finally, this also brings up a very important debate regarding API versioning, but I will leave that for another night.

Cheers,

Gui