Why Time Travel is a Necessity

"Time is money", but if it were so important then why do we continually ignore it when we build our systems?

Sean Mcgrath in a recent entry used the word "temporal coupling". The notion is that systems are coupled in time when activities have to interact at the same point in time. For protocols like two phase commit, it has strong temporal coupling in that the participant need to interact in lock-step (i.e. synchronized) manner.

Another form of temporal coupling is the notion that dependencies of events occur in a pre-ordained manner. In imperative programming languages, the sequence of instructions and its ultimate execution is defined ahead of time. That is events are coupled to each other on the axis of time. Functional systems and dataflow systems do not exhibit this kind of coupling, the execution of an activity is determined only at the time of execution.

In fact, the pattern of delayed commitment (a.k.a. as late binding) is in fact quite general and pervasive. It is the basis of many loosely coupled styles such as dynamic typing, queried references, self describing ontologies, reactive behavior, optimistic transactions and even prototype-based classification.

However, there's one last restriction that we can remove to further reduce temporal coupling. We can ignore the natural flow of time itself, that is, that time always moves forward. In other words, we can go backward in time, that is do some time traveling.

One would think that time travel is an extremely impractical feature to build into one's system. However, on the contrary it pervasive in the requirements is something one can't avoid. Have you never seen a user request changes because an event that happened in the past was never recovered and only discovered in the future? When analyzing complex behaviour, don't we always benefit by walking backwards in time?

Time traveling can be quite complicated to reason about as explained in surprising detail by "Temporal Anomalies in Time Travel Movies". Fortunately, several practitioners have built patterns to handle the situation where its necessary to go back in to time. Kent Beck and others have put together a collection of patterns to handle "Time Travel", Martin Fowler has something related in "History Patterns". It's important for practitioners have this knowledge in their toolbox, there's just no need to re-invent the wheel on this extremely complex topic.

In the end, the ability to go backwards in time is a valuable capability. It forms the basis any reasonably useful version control system. The ability to go back and time and correct mistakes in the past is just as valuable. After all systems tend to fail, communication links tend to fail even more, its simply a normal occurrence to compensates for missing or incorrect information that you may have recorded in the past. In fact, going forward, the concept of provisional knowledge can be quite valuable for coordination.

Provisional knowledge, is knowledge that you assume to be correct for now, even if you know in the future that this will most likely will change. It allows parties to synchronize activities without truly achieving complete agreement. In fact, I would consider this yet another loosely coupled style, that is Provisional opposed to always Final state change.