Why “future-proofing” is a lie we tell ourselves

You can’t out architect time

This statement will ring differently for different people. We will have the people who are fresh to the industry and those who have never encountered hardship and thus seen a project fail. They are bright-eyed and full of optimism and will find this statement shocking and appalling! The jaded intermediates who have had more than a few things go wrong, but did not have the luxury to find the answer why (or how to prevent it in the future) raising both fists in the air in triumphant emphatic agreement, and then the seniors who are sitting there thinking “Now wait a second…”

When I first started programming, I worked on a software system that was 20 years old and written in Java. My first real challenge. I needed to add a new feature to the system, however I was blocked due to multiple protections I was told were in place “for future proofing”.

My task was simple: Add a new type of notification. However, during digging, I saw that it wasn’t so much “future proofing” as it was “time locking”. Every design decision seemed to scream “This is the way it will be forever”, as if an obsidian pillar in code. And it was my job to go to the single source of truth and say “Your truth has changed”. Where did that single source of truth lie? Deep at the heart of the notification service.

The specific mechanism has faded. Was it a final class, a hardcoded enum, a labyrinthine XML schema? The memory of the syntax is gone. What remains is the memory of the structure: a deliberate, intricate barrier designed not to guide change, but to declare a perimeter. My five lines of new logic were not the problem. The problem was the fifty lines of architectural ceremony I had to perform to prove my logic was worthy of entry. I wasn’t extending a system. I was petitioning a tribunal that had long since adjourned.

We build systems to interact with the world. The world will change, change in ways we can never predict. 20 years ago, who could have predicted smartphones? 10 years ago, who could have predicted AI? Today, who can predict the next thing we have to rewrite our software to accommodate?

Build systems not to perfectly fight the change of time. Build systems to perfectly flow with the change of time.