The Fallacy of Future-Proofing

Engineers love to build abstractions. We try to anticipate how a system will change in the future and build hooks and interfaces to accommodate those unknown changes.

This is almost always a mistake.

Future-proofing assumes we can predict the future. We cannot. When the future actually arrives, the requirements are always slightly different than what we anticipated, making our clever abstractions not just useless, but actively harmful. They become obstacles we have to work around.

The best way to future-proof code is to make it easy to delete. Write simple, concrete code that solves today's problem. When tomorrow's problem arrives, rewrite it.