I am at the gym, on the treadmill with my phone, which contains my running plan. There is just nowhere to place it. There is a holder for an iPod, though - the iPod hasn’t really been around for a long time anymore. This implies the treadmill was built at a time when the iPod existed, that it was an essential part of the experience, and that the treadmill couldn’t be imagined without it.
Yet the treadmill is still here, while the iPod was discontinued after 20 years of service. The iPod holder isn’t a mistake. It’s a commitment that outlived its assumptions.
While I was running, I was thinking about how I could make this treadmill technologically useful after 20 years. I had two thoughts: first, adding a USB-C cable, and second, making the control panel modular, because hardware evolves.
How to build that lasts
The first idea was as good as adding the iPod holder: USB-C looks universal now, but will it hold up for 10, 20, or even 25 years? Even in a world without iPods, the first smartphones could easily fit in that spot, but modern smartphones are increasing in size with every generation.
We’ve had USB for a long time, but with different connector types. And even though the Type-C connector hasn’t really changed in form, the hardware within has changed. So even if we agree on a USB-C port, there is a need to update the hardware and software periodically. This opens up new compatibility issues between the treadmill and smartphones. And the question that remains: how will the treadmill of the future transfer data at all? Maybe completely wirelessly. But that, too, is a commitment.
Which leads to the second point: the control panel needs to be modular so that its hardware can be upgraded independently.
Hardware and software have different lifecycles. The user interface can evolve through software updates without replacing the physical controls. But eventually, the existing hardware will no longer support the next software update. At that point, the hardware needs to change as well.
Even within the control panel, those lifecycles are not necessarily the same. The display might become outdated or fail while the system-on-chip is still perfectly adequate — or the other way around. Individual hardware components have lifecycles of their own.
And then there is the treadmill itself. Its motor has little reason to share a lifecycle with the user interface. It might fail, become inefficient, or simply remain useful long after the electronics around it have become obsolete.
Even though we see the treadmill as one system, it does not have one product lifecycle. In fact, it is a system made up of different subsystems, such as the interfaces for controlling the system or transferring data, each evolving on its own timescale.
Learning from buildings
Stewart Brand makes an interesting observation in his book How Buildings Learn. He states that the magazine Architectural Digest has surprisingly little about buildings and much more about interior design.
Brand argues that this is because people change their interiors much more frequently than they build or fundamentally change their houses.
This leads him to an interesting observation: different parts of a building change at different speeds, and an adaptable building must let them slip past each other. Otherwise, the slow layers block the fast ones, and the fast ones tear up the slow ones. Many buildings, he notes, are demolished early simply because their outdated systems are too deeply embedded to replace. Brand takes this idea further with a framework of shearing layers, based on the work of architect Frank Duffy. He calls them the Six S’s:
Site - the geographical location; effectively permanent.
Structure - foundations and load-bearing structure; decades to centuries.
Skin - exterior surfaces: façade, roof, windows; typically replaced or refurbished over decades.
Services - wiring, plumbing, HVAC, elevators, communications; replaced more frequently.
Space Plan - interior layout: walls, doors, floors, room arrangement; can change every few years.
Stuff - furniture, appliances, possessions; can move or change constantly.
For Stewart Brand, these layers sit on top of each other, and mapping a system such as the treadmill to his framework is tempting. At first glance, it seems impossible: Brand looks at buildings, which are hardware, and software seems to break the model. But only if we look at software as one layer. The motor firmware may stay unchanged for fifteen years, while the user interface might change every few months. They are not one additional layer, but two individual layers and should be treated as such.
The structure of a system
We have seen this before in personal computing, where software is built in layers of abstraction: from the hardware abstraction layer to drivers, to the operating system, to user applications. These layers also change at different speeds. On each hardware layer sits another layer of software, with a lifecycle of its own.
Like the demolished buildings, the treadmill has the same problem. At some point, the hardware will no longer support the next software update. And if that hardware is built into the console, the console goes with it. The motor and frame might be fine. The treadmill still ends up as scrap.
Today
Brand also quotes Churchill: “We shape our buildings; thereafter they shape us.”
The same can be said about systems. We shape systems, and they, in return, shape us.
In our work developing systems, we draw boundaries often determined by functionality. That decision is carried downwards to logical components, where we again draw boundaries between subsystems and allocate functionality to electronics.
Brand suggests another criterion: draw them where the pace of change differs. And make the interfaces across those boundaries the most stable part of the system.
Houses need wiring, which is kept in the walls. In order not to break down a perfectly good wall, empty conduits are added for later use. The wiring will change faster than the walls; the empty conduits give room for change. A system does not need empty conduits, but it still needs room for change. The motor will keep the treadmill alive for a long time and can live independently of the user interface, which can be updated. Yet both the user interface and the motor control are running on the same chip. If the chip needs replacing because of the user interface, the motor control has to go with it. That is what drawing boundaries by function looks like.
The treadmill was designed in a world in which the iPod was important enough to deserve its own place on the control panel. Almost two decades later, that decision is still there, shaping how I can use the treadmill today. Nowhere to place my phone.
I don’t think the lesson is that the designers should have predicted the smartphone, USB-C, or whatever comes next.
They couldn’t.
The question is whether they needed to.
They didn’t.
What they needed was room for change.
So the next time you are looking at your system architecture, pick one subsystem and ask yourself: How long do I expect this part to remain useful?
Then look at everything it depends on and everything that depends on it.
Do they change at the same speed? And if they don’t, can one change without forcing the other to change with it?
Maybe that is the question I should have asked instead of where to put my phone.