I’m currently reading Steven Pinker’s recent book “The Stuff of Thought”[1] in which he discusses how the structure of language provides insights to how the brain works. It’s one of three books I have on the go at any given time. Never have enough uninterrupted time to just sit down and read the whole thing – I guess that’s a lesson right there in how the modern brain works. I’ll give you one example of the kind of gem I’ve found in this book – it’s something “traditional” Information Architects will appreciate because it’s in reference to web advertising rates: “[The phrase] Digital camera can be bought for seventy-five cents a click, whereas digital cameras fetches a dollar and eight cents. The advertisers know that the plural is more likely to be typed by people who are planning to buy a digital camera, though they don’t know why. The reason is that a bare noun like digital camera is generic, and is likely to be typed by someone who wants to know how they work. A plural like digital cameras is more likely to be referential, and typed by someone who wants to know about the kinds that are out there and how to get one.” [2] (Emphases are in the original). That’s pretty cool. The addition of a single letter signals the searcher’s intent. If only we paid as much attention to our users’ intentions every day so that we could anticipate their needs more effectively. Unfortunately, the profit motive is much less directly tied to our predictive capacities for most user interface scenarios. Unless you’re Apple. Or perhaps Google.
Another interesting discussion in the book is about how the brain thinks about causation – its timing (past, future) and effects. I won’t go into the details, but I just encountered a scenario at work and realized it’s similar to the sort of thing that Pinker is writing about. The scenario is this: I want to enter my hours that I logged last month, but I was busy and didn’t log them until today. Unfortunately, the item against which I log hours has in the meantime been closed – it’s in a state that does not allow it to accept hours to be logged against it. You may recall from previous posts that an item is either a managed artifact (source code, requirements, documentation) or a process item (change order, defect report, feature request). Managed artifacts are the things we version. Process items also evolve in time but we are not so particular about assigning versions to them. Their evolution is more of a continuum of changes. Most of the time we don’t feel any need to take the whole lot and checkpoint it, since we can’t compile them – they’re not source code – and mostly we care about their current state rather than their historical state.
This scenario the one exception to the rule. The correct rule here should be this: If I want to log work against the item, then its state as of the date on which the hours are logged is the relevant state. The current state (closed) is irrelevant. We want to ask the question “What would have been the state of the item if I had logged the hours on the day that I worked?” The insurance industry is quite familiar with this concept. They call it as at to distinguish it from as of. I guess policies change a lot, and by the time you call in to complain about your coverage, or to inquire about your coverage, what matters is not so much how things look today, but how they looked at the time the relevant incident occurred. This is more common than you might imagine. In benefits programs, for instance, they can tell you “as at last month you would need to work another two months to accrue 11 days of vacation” whereas “as of today you have 9 days accrued” and “as of next month you will have 11 days accrued.”
The calculations get pretty complicated when you get down into the guts of reporting time-based information for both process items and managed artifacts. The details are very different for the two types of items. For managed artifacts you want to reconstruct the state of all of the constituents in the module as of the requested date. For process items you want to reconstruct the state of all the calculations as of the requested date. This has a huge impact on the kind of historical information you would want to record for the two types of items in your repository.
[1] Pinker, S., The Stuff of Thought, 2007 Penguin Books
[2] ibid, p165