Many times I have been working on a project, and the first thing my mind starts with is how to build it so that it is future proof. We often want our work to last a long, long time. It’s part of the reason we like doing software in the first place.
In contrast, I am constantly reminding myself to start with simplicity. Let complexity and future proofing evolve with the application, and only apply it when the need for flexibility has been established, or the potential of change is certain. Obviously, if the simple implementation is also flexible, why not start with both.
Here is a good example. When saving data in an application there are any number of storage solutions. You can save to the Cloud, disk, no SQL data stores, or relational databases, plus other options from time to time. Do you write your persistence code based in interfaces right out of the gate, so that at a later time you can implement persistence to a different data store? The answer is based on your response to the question,” how likely is it that you will be changing the target persistence? Or, how complicated is it to write the software in a non-deterministic manner?”
Using software generation tools it can be easier to write to an interface, and have the tool generate persistence for different targets. If that is the case, then why restrict your options. If you are hard coding the whole thing, then keep it simple. Expand when necessary.
Those are thoughts from my current experience. I’m sure I’ll change them in a few years, as I continue to learn from those more experienced than myself. In the mean time, why not add your comments to share your opinions. You know you want to.
Cheers,
Ben