Time – the forgotten dimension
Over time your mental model evolves. With your next bit of information your model improves one step further. But that’s not the aspect of time I want to talk about. The system at hand gets older, time passes by, bits and pieces of the system change. That’s the aspect of time I want to talk about.
Time is a very important dimension in your mental models. Time is difficult to include in a 2D image of your model. Hence time is often forgotten, not only in visualization, but also in thinking about it.
There’s many aspects of a system that you need to keep in mind, when it comes to time. Maintenance, extension, degradation, and so on.
When it comes to bikes, you need to take care of lubrication, replace parts, clean it, you need to repair a flat tire. So when you buy a bike or build one yourself, is that something you have in mind? You think about, how cool it looks, how good it rides, how comfortable it is. You think about price and availability. But I guess you rarely think about the items listed above.
When we build an IT system, we think about a solution for a problem at hand. We think about deploying it, operating it, using it. But what about extending it, fixing bugs, migration, aging data. In my 25 years in IT I have seen quite a few systems, have worked on and tested several. Did we build the right thing, did we build the thing right? Does it work? Can I deploy it? These were the main drivers.
Sometimes we thought about, what happens in case of an error? What happens in case of a failover? Is this implementation easy to extend and maintain? That is a bit looking into the future. But that is not the main priority.
What happens to the records in the database in 1, 2, 5 or 10 years? How many records can we store? How many can we handle? What happens when certain elements we use are deprecated? What happens when we have to sunset the application? Can we support the migration to another system? Honestly, who thinks about these questions? We don’t have time to think that far (pun intended).
I had it in the last post about the waterfall cascade in cyclic models. On paper these models look nice and lean and sexy. But once you reach sprint 3 it starts to get messy. Sprint goals are not met, you have tickets that go into the next sprint. Tickets are swapped and re-prioritized. There are now several epics in progress in parallel. You have a growing amount of tickets in the backlog. More priorities change. You gained insights on dependencies and what needs to go before what. You start delivering first artifacts. Feedback arrives, more stories, bug reports, the backlog grows. You realize dependencies between progress and upcoming timelines.
You have meetings that look back (lessons learned), that plan the next sprint (sprint planning), that look into the future (refinement) and those that look at the current status and problems (daily stand-ups). In parallel you work on the current topics, you write and refine new tickets, you look at other people’s code, you test other tickets, you deliver an artifact with changes you implemented last week, you monitor the environment and you gather feedback. And then there are most probably topics outside your current team’s work that need attention.
This is reality after only a few weeks for the rest of the life of the product / project. But do you find that visualized in any models? I tried to explain this to some folks who were new to IT over the last 2-3 years, why some things are not that clean as the models look like. It scared the shit out of them, but it also helped them understand.
One last aspect. History is probably not everyone’s favorite subject in school. But when you know the past of a system, you know where it comes from, what motivations where behind it, which biases do exist in the system. This applies to countries, as well as companies and also products. It applies to every system. Look into its history. It might tell you a lot about its future.
Time is a tricky dimension, so practice your systems thinking skills to keep time in mind. Pick any object that’s around you right now. Think about where it came from. Why does it look like this? How did its predecessors look like?
How will this very object look like tomorrow, next month, in a year, in 10 years?
