Wide Awake Developers

« Circuit Breaker in Scala | Main | Metaphoric Problems in REST Systems (audio) »

Time motivates architecture

Let's engage in a thought experiment for a moment. Suppose that software was trivial to create and only ever needed to be used once. Completely disposable. So, somebody comes to you and says, "I have a problem and I need you to solve it. I need a tool that will do blah-de-blah for a little while." You could think of the software the way that a carpenter thinks of a jig for cutting a piece of wood on a table saw, or a metalworker thinks of creating a jig to drill a hole at the right angle and depth.

If software were like this, you would never care about its architecture. You would spend a few minutes to create the thing that was needed, it would be used for the job at hand, and then it would be thrown away. It really wouldn't matter how good the software was on the inside--how easy it was to change--because you'd never change it! It wouldn't matter how it adapted to changing business requirements, because you'd just create a new one when the new requirement came up. In this thought experiment we wouldn't worry about architecture.

The key difference between this thought experiment and actual software? Of course, actual software is not disposable. It has a lifespan over some amount of time. Really, it's the time dimension that makes architecture important.

Over time, we need for many different people to work effectively in the software. Over time, we need the throughput of features to stay constant, or hopefully not decrease too much. Maybe it even increases in particularly nice cases. Over time, the business needs change so we need to adapt the software.

It's really time that makes us care about architecture.

Isn't it interesting then, that we never include time as a dimension in our architecture descriptions?


I find the "some amount of time" lifespan is very difficult to grasp.

It's easy to imagine the software I'm building today living on for the next year, maybe the next 5 years, maybe longer. It's fun to think of usage/functionality/stability will always be heading up-and-to-the-right. That's part of what makes a project worth working on day after day.

It's much less fun, to imagine a reality where the software I'm creating is far departed from it's original use or maybe is no longer even needed. Maybe it's an exercise I/we need to get better at.

Any ideas for how to turn "some amount of time" into something that could be useful in a discussion/description about architecture?

My initial thoughts have to do with potentially using an event based concept of time over a calendar based one...seems like I could more easily wrap my head around something like "storage costs are reduced by 10x", "mature solutions/languages for utilizing multicore processors are available", or "Google enters my market" over "6 months", "18 months", "36 months" from now. Just my initial thought....

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)