Be a reed coder, not an oak one
French fabulist Jean de la Fontaine wrote “The Oak and the Reed” in 1668, taking inspiration from one of Aesop’s Fables (which allegedly might be about a willow instead of a reed, ahem). Admittedly long before anyone tried “coding” anything at all. And yet, I think that fable has a lesson to give to most software engineers out there.
You cannot prevent future disasters
Let’s get one thing out of the way: you are not prescient. So even if you happened to have some uncanny way to predict the future, chances are you can’t tell things all that clearly all that far ahead.
You cannot know what the users of tomorrow will be like or what they’ll expect/need from your code. You cannot know what kind of rival (or mutually beneficial) software will come up, which your code will need to adapt/connect to, or what platforms your code will have to become compatible with.
Your code cannot be made so sturdy it will last forever. That is clearly a pipe dream. Stop trying.
Is it okay to only focus on the present then? Nope
If you only focus on the current instructions/scenarios/use cases you’ve been given and don’t spare a single thought about future evolutions, then your code will soon be a putrefied pile of rotting spaghetti that every other coder will feel quite sick about touching, and you yourself will get headaches in no time just stopping it from blowing up.
So what? You have to prepare for a future you have ABSOLUTELY NO WAY of predicting… Doesn’t it sound like a paradox? Not really.
That’s where the fable of The Oak and the Reed can come in handy. Facing the wind, the oak resists while the reed bends. If the wind is mild, the oak looks sturdy and cool, while the reed looks weak, sure. But if a true storm comes — do not kid yourself, a true storm is always coming, it’s only a matter of when, not if — then the oak gets uprooted like a fool while the reed bends as normal and survives.
Code like the Reed
Your code does not have to accommodate for a future you cannot predict. Instead, it should remain as simple, readable, and flexible as possible. Easy for anyone to read, interpret, and modify. So that it may be later be modified as the circumstances require.
Let your code be bent. Easily. Repeatedly. Any time. Any way. By you or by others.
That is the better way. If your code is easy to modify, then it will easily be adapted to any whim of fate, any unpredictable event the future throws at you (or whoever takes on the task of maintaining it).
In the great scheme of things, there is so much more debt than value in a big awkward oak of a pile of legacy code no skilled team could ever refactor…
…than in a maybe measly-looking reed of super-flexible code that anyone could pick up and adapt easily to new needs, circumstances, trends, platforms, or whatever else the future will invent.
TL;DNR
Write your code so that anyone could read it, understand it, and modify it as easily as possible. That should be your goal even if no one else is ever supposed to read your code because you cannot predict what the future will bring, and you yourself will be a stranger to your own code in a few weeks.
