Engineering for a distant future

How do you give someone a warning when they won’t exist for a hundred millennia?

That’s the problem of long term nuclear waste messages. Aside from all the physical engineering problems of securing radioactive material safely for long periods of time, designers also face the social engineering problem of ensuring that curious or greedy humans won’t undo their work by digging the waste back up again when they have forgotten how dangerous it is.

This problem gets more interesting the longer you think about it. We can’t rely on language: history tells us that languages shift and change in meaning. We can’t rely on the durability of digital media: no storage device we have built so far has lasted longer than decades. We can’t even rely on colours and shapes: these mean different things in different cultures.

Several projects have suggested ways to solve this problem. In 1993 a report recommended a series of messages or experiences designed to evoke feelings of danger, accompanied by large scale physical symbols, such as spikes jutting from the ground, a landscape of rubble and streets that lead nowhere. The problem with such solutions is that it is easy to imagine humans being intrigued and excited by these mysteries, pushing through the rubble field to discover the forbidden secret.

Perhaps the strangest - and not entirely serious - suggestion is to use cats, genetically engineered to change colour in the presence of radioactivity. This idea, proposed by Francoise Bastide and Paolo Fabri, depends on the apparent durability of the human relationship with cats and, alongside the ability to change colour, would depend on folklore, legends and other cultural phenomena to carry the idea that, when your cat changes colour, you should run away. (Naturally, this idea has gained some following on the Internet: it’s worth taking 15 minutes to watch this film.)

In the field of enterprise technology, we don’t build systems to last 100,000 years. But we do face a similar problem, with timescales which may be comparable, considering the pace of innovation and the processing speed of computers. When we design and build a system, we cannot fully predict the environment that it will operate in (other than that it will be implacably hostile). We might have an idea of what that environment looks like on the first day of the first release of the first version: we know how we specced the servers, we know what systems it interacts with, and we have an estimation of throughput and capacity. But our expectations and reality diverge almost immediately: a change to a related system greatly increases user engagement, and drives more traffic to our system. An API which we intended for infrequent use by back-end systems is incorporated into a mobile app, changing the role and nature of our system. And, after a while, someone invents a new technology which changes the nature of networking, or databases, or some other fundamental component of our system.

Consider core banking systems from the world of finance. They are notoriously slow to change, meaning that many banks are still running code that was written in the 1980s. Think about what that world was like: a world of branch banking, where people wrote cheques to make payments or even to withdraw cash. A world of batch processing, where online processing shut down every night, and transactions took days to clear. Those same systems are now operating in a world of continuous availability, ubiquitous connectivity and expectations of immediate transaction completion. If those systems were people, they might feel as if they had travelled into a distant future where everyone speaks a different language, thinks in different ways, and moves at dizzying, incomprehensible speed.

There are, of course, techniques which we can use to help our system survive in a distant and unpredictable future. We can encapsulate our data and functions in well defined APIs that offer a consistent contract, no matter what the environment is around them. We can decouple components so that they can be changed independently. We can design systems capable of scaling to an arbitrary degree. And we can build continuous refactoring and adaptation into our engineering practices.

But these are not easy disciplines to stick to, especially in the face of short term project pressures that do not care about a distant future. One of our biggest challenges is figuring out how to balance short term outcomes with long term effectiveness.

Fortunately, this sort of problem is interesting to solve, just like the problem of long term nuclear waste storage, and just like the other interesting engineering problems I wrote about last week. As I also wrote, I’m currently recruiting for the first ever UK Government Chief Engineer, who will work on some of the most interesting engineering problems in the country. If you think that sounds like something for you, please apply.

(Views in this article are my own.)