Long Lived by Design

Picking up where my last post left off, the issue of data longevity is specially important to developing economies where the process of digitizing government records and making government services available online is just beginning. The lessons to be learned from data loss from the early adopters in more developed economies should be taken to heart.

There's no question that this is a well-understood problem and many projects are tackling different aspects of it. For example, open standards such as ODF reduce the risk of unreadable data. Digitization and hosting of content by service providers offloads the problem from individual consumers to service providers who are, presumably, better suited to deal with it. At the cutting edge, there's even talk of using bacteria for long-term data storage!

My point is not that adequate steps are not being taken. My point is that product design should incorporate principles with longevity in mind. What might these principles look like? A great place to start is by looking at the Clock of the Long Now, conceived by Danny Hillis (of Thinking Machines fame). As he explains the genesis of the project:

I want to build a clock that ticks once a year. The century hand advances once every one hundred years, and the cuckoo comes out on the millennium. I want the cuckoo to come out every millennium for the next 10,000 years. If I hurry I should finish the clock in time to see the cuckoo come out for the first time.

This seemingly quirky endeavor is actually a deeply insightful way to examine our notion of time and its impact on technological progress. Hillis lays out a list of design principles for his 10,000 year clock.

• Longevity: The clock should be accurate even after 10,000 years, and must not contain valuable parts (such as jewels, expensive metals, or special alloys) that might be looted.

• Maintainability: Future generations should be able to keep the clock working, if necessary, with nothing more advanced than Bronze Age tools and materials.

• Transparency: The clock should be understandable without stopping or disassembling it; no functionality should be opaque.

• Evolvability: It should be possible to improve the clock over time.

• Scalability: To ensure that the final, large, clock will work properly, smaller prototypes must be built and tested.

These principles seem to me to be broadly applicable. If your product, software or hardware, may be used for any duration longer than five years, you would do well to consider each of these issues (adapted for your specific situation) and how you plan to address them in your product.