How will my software be used in two years’ time?  What extra fields should I add now so that they can be used in “a while”?  Should I make these fields optional until some extra data is available next year?  Is data validation necessary, or will it become a maintenance nightmare?

The future is a closed book to us in most ways, yet many of the decisions we have to make might be different if we knew what was about to happen.  The Bible reports a story told by Jesus about a man who was doing well as a farmer. If fact, he was doing so well that he needed to upgrade his storage facilities.  He planned to take it easy once the upgrade was complete, but he never made it because he died that night (see Luke 12:16-21).

So what should we do when we need to do data modelling to match future usage?  Sometimes it is made easy for us because someone else makes the decisions and tells us what assumptions we should make!  Often, however, we are the ones who must make the choices.

There is a saying that past behaviour is the best predictor of future behaviour. While many take issue over the detail, it is a good starting point.  If all attempts to computerise systems within a company have failed in the past, the next one is more likely to fail also.  If users have done their best to improve the quality of stored data over time, it is more likely that validation of data will not cause a user revolt.

Design is always concerned with the future, but don’t overdo the guesswork.  We can aim for a dream future or a predictable, extrapolated future.  Risk increases as we move away from minimal change based on a sensible predicted future into a fantasy world of hope.  Success is most likely when we base our designs on what already exists.