Stop Predicting the Future of Your Program

I'm afraid we've all fallen for this trap earlier in our careers. At least I did.

The strong desire to write elegant code that allows my program to account for future requirements was something I was proud of. Until I realized I added complexity for a future that never came. Those requirements never manifested and I had to live with poorly made decisions. I can't provide a reliable guideline on how to go about this but I want to invite the reader (and my past self) to avoid trying to predict the future.

Being able to understand software requirements from the start is very rare. This is the nature of the tech industry in general, things evolve and change so rapidly that you might do more damage than anything in trying to stay ahead. Products are born and die quickly, so you have to be clever about what your focus should be on. I consider this to be powered by one simple factor: time is a precious resource. Whenever I think a substantial change feels needed I take a deep breath and give it way more thought before committing. Be nimble and attentive to where your time is spent.

I believe I was too dogmatic in my younger years. As I worked on a growing React project I made two mistakes that I remember clearly: committing to a specific folder structure, and refactoring our Redux state management. When I lay them out like this, they could seem reasonable. Eventually, they slowed down development more than I liked. My lack of understanding of how software evolves had me committing to this inflexible folder structure. I can't remember the details anymore, but I recall that it was a pretty flat folder tree. That meant that some completely unrelated components were next to one another, which made navigating the codebase frustrating. In the other case, I invested a lot of extra time into planning and refactoring our Redux stores, a refactoring that never saw the light of day. More urgent issues came up that required my full attention.

Both cases shared my lack of understanding that software evolves in ways we can't predict most of the time. This was not just anecdotal, Martin Fowler in "Refactoring" highlights this by inviting you to focus on the needs currently understood of your program. Speculation attempts on future flexibility are far less valuable than focusing on delivering greatly designed software for the needs we understand now. By adding unnecessary flexibility you add complexity to a system that will eventually become harder to change and less reliable.

Thoughts

I learned to be very cautious about my attempts to add flexibility to any program I contribute to. I bet on simplicity and resolving problems I'm aware of now, rather than trying to predict the future and increasing the complexity of my software. I tend to agree with Martin Fowler's general philosophy on small incremental changes, that would have made my time refactoring state management worth it. This doesn't mean running away from attempts to make things more flexible, experience will teach you when that is a good idea. The one thing you can't go wrong with is refactoring your system in a way that makes it easier to add functionalities without trying to predict what those functionalities will be. The way I look at it is that I prefer to focus on extensibility over flexibility. In other terms, design a system that can be easily extended rather than a system that takes into account many possible (but uncertain) future requirements.