Where does all the time go?

by Sean McGrath

November 19, 2007 —

In my formative years, I was lucky enough to be exposed to JSP. No, not JSP
as in Java. The other one. The previous one. The one that stands for Jackson
Structured Programming[1]. This led me to JSD (Jackson Structured Design)[2] and,
to cut a long story short, the wiring of my brain was changed forever.

JSP and JSD are software development methodologies. The details are not particularly
relevant here. The relevant fact is that both methods feature a strong focus
on boiling computing down into an activity that changes the state of digital
information through time. It's all about things changing as time marches inexorably
forward.

What happens when you author a word processor document on your PC? You change
the state of data (your hard disk) from the state it was in prior to creating
the word processor document, into the state it became afterwards. What happens
when you update a database record? The state of the database at time T (before
you started) is changed to a new state at time T+1 (after you have finished).

Crushingly obvious isn't it? So much so, I'm tempted to call it a truism. I
would do if not for the fact that we spend an inordinate amount of time in this
industry lovingly hand-crafting systems so that they have the concept of time
built in to them.

When creating documents, we cannot just let change-through-time look after
itself. If we wish to be able to trace how things changed over time we need
to take explicit action - either versioning documents ourselves or installing
some custom application on our machines that will do it for us.

When creating database records, we cannot just let change-through-time look
after itself. If we wish to be able to trace how things changed over time we
need to take explicit action - either versioning database records ourselves
or perhaps buying into a less-than-commonplace database system that implements
so-called "point-in-time" data access.

Also in my formative years, I was lucky enough to be exposed to a VAX. No,
not that type of VAX[3]. The Digital Equipment Corporation kind of VAX[4]. VAX
machines generally ran an operating system called VMS[5]. One of the great things
about VMS is that it had an innate understanding of time. If I create a file
on a VMS machine, let's call it "foo". The file will be stored as
"foo;1" When I modify the file foo, I end up with a new file "foo;2".
The old foo remains, frozen in time. No thought required on my behalf. Time
looked after itself.

When I look around me at all the trouble and design effort caused by our mainstream
operating systems not having this built-in concept of time, I cannot help feeling
that the industry has missed an important trick.

Over the years, I have often benefited from thinking about computing in terms
of time. I have often wished that the machines would do some of the thinking
for me. These days, more and more applications for managing digital content
are providing time-oriented services. Generally called versioning or perhaps
change-control. Unfortunately, they all do it differently and they all do it
at levels above the level where (I feel) it really belongs. Namely, baked right
into the file system.

Perhaps this will happen. Some time. It won't be a moment too soon as far as
I'm concerned.

[1] http://en.wikipedia.org/wiki/Jackson_Structured_Programming

[2] http://en.wikipedia.org/wiki/Jackson_System_Development

[3] http://www.vaxusa.com/

[4] http://en.wikipedia.org/wiki/VAX

[5] http://en.wikipedia.org/wiki/OpenVMS

ITworld.com