Jettison everything else, then, and lay hold of these things only, few as they are: and remember withal that it is only this present, a moment of time, that a man lives: all the rest either has been or may never be.
These words came from Marcus Aurelius, a roman emperor and among other things a philosopher. This thought was actually a part of a larger idea found throughout his writings in that a person’s life can only be measured in the present as in his mind it is the only thing that can truly be taken away from someone. The past is done and the future isn’t guaranteed.
Great, so what the hell does that have to do with programming? Truth is, it has a lot to do with it.
When it comes to programming, certain people… not going to name any one (Me)… tend to get overwhelmed playing the prediction game. It’s not good enough to see what I’m doing now, but I’m always planning about 8 steps ahead. Problem is, it sounds like a good idea but in reality can create over engineering and paralysis.
What if in the future it needs to be web service based?
What if in the future a user will need multiple addresses?
The question I should be asking is: Will all this What Ifing help anything get done now or will it just make the system overly complex for no good reason? Am I really smart enough to predict where the system will go in the future?
The customer, like the future, is a fickle thing. You can’t predict where a customer might be two months from now. What you do know is where the customer is right now. Just like Marcus wrote “all the rest either has been or may never be.” You can put in 20 extra hours a week creating a massively robust and fluid front end web design only to have the customer decide a year down the road that it needs to be a standalone app. This is something that cannot be predicted. It is the way of the unknown. You can only do best by what you know now.
Are there ways to protect yourself? Sure. Things like abstraction and decoupling can help at least make the change be less painful and overall are good practices anyhow. Things like ORMs can help against database changes (You know when sql server is just “SURPRISE” replaced with oracle), service oriented architecture to hide the underlying data processing, repository pattern, ect ect ect. There are many tools out there to help make it easier when a large chuck of a project is called to change heavily or to be completely redone.
Fact is, things will change and you can’t predict them. The best you can do is create architecture that allows for change rather than creating one that assumes what those changes will be. Live in the now, let the future come as it does. For every step in the future you try to predict, another assumption is laid upon a foundation of assumptions. If any one of those turns out to be false, the whole thing will come crashing down. Don’t spend a lot of time on creating things you can’t prove will ever be needed since in the end you have to get something out at some point. In the real world a working program now is better that a crazy advanced magic one that still isn’t out.