Persistence Is Not Continuity
Saving is not remembering, and movement is not life. One sentence from a standard document that turned out to be a testable specification rather than a slogan.
Date
Category
Writer
My grandmother kept a tin of buttons. Not a button collection, which is a different and sadder thing. A tin, in a drawer, into which buttons went when a shirt was thrown out, and out of which buttons came when a shirt needed one.
The tin had no system. Nothing was sorted, labelled, or counted. And yet she could reach into it and produce, within a few seconds, a button that would do. I have thought about that tin a great deal while building software, because it does something almost no software does: it accumulates without organising, and it stays useful anyway.
What made it work was not the tin. It was that she had been putting things into it for forty years and knew, in her hands rather than her head, roughly where in the tin the older layers were.
The sentence that settles arguments
There is a line in JEFIELD's standard document that I have now used to resolve at least a dozen design disputes:
Persistence is not continuity, and movement is not life.
It reads like a slogan. It functions as a specification, which is the only reason it is still there.
Persistence is the solved half
Persistence means the bytes survive. You wrote something, you closed the tab, you came back, it is still there. Every storage layer built in the last forty years does this competently. It is table stakes. Nobody in the history of software has loved a product because its writes were durable.
Continuity is a different property. Continuity means the state survives: not only the content, but your position in relation to it. Whether this is the first time you have seen this thing or the ninth. Whether you left it mid-thought. Whether three weeks have passed, and, critically, whether three weeks is a long time for you specifically or an ordinary interval.
Persistence | Continuity | |
|---|---|---|
What survives | The content | The content and your relationship to it |
Question it answers | Is it still there? | Where was I, and how long ago? |
Cost to build | Low. Solved by the database | High. Requires an event record, not a state record |
Failure mode | Data loss, which is visible | Amnesia, which is invisible |
Who has it | Everyone | Almost nobody |
Table 1. The two properties are routinely conflated because the first is a precondition for the second.
The reason the distinction matters practically is that continuity cannot be retrofitted. If your storage layer holds current state rather than an ordered record of events, the information required for continuity was never written down, and no amount of later feature work can recover it. You cannot compute how many times someone returned to a thing from a row that only knows what the thing currently says.
This is why JEFIELD's record is an append-only log of events rather than a table of notes. It is not architectural fashion. It is that a table of notes has thrown away the only data continuity is made of.
Movement is not life either
The second half of the sentence exists because I had to name a temptation before I gave in to it.
When you build a space with a character in it, the obvious route to making the space feel alive is to make the character move. Idle animations. Random wandering. A blink every few seconds, a tail flick, a stretch on a timer. It works, in the narrow sense that a moving thing reads as animate to the human eye within about two hundred milliseconds.
It is also a lie, and a cheap one. Random motion carries no information. A cat that wanders identically whether you visited yesterday or last month is a screensaver in a costume, and the person watching it is being invited to infer a relationship that does not exist.
So the rule became testable, and it now gates every behaviour in the product:
Note carefully what the rule does not say. It does not say the behaviour must always differ, or differ visibly, or differ in a way a user would notice within one session. It says the capacity must be real. The difference between a system that could respond to your history and one that merely appears to is not observable in any single session, and is the entire difference in the long run.
The uncomfortable consequence
Holding this line costs things you would like to have.
After a long absence, JEFIELD's cat has very little to say. It has no rhythm for you yet. A world containing two visits genuinely does not know whether three weeks is unusual for this particular person, because it has no distribution to compare against. The honest behaviour is near-silence.
Every instinct says patch it. Write a warm line for the returning user. It has been a while. Ten minutes of work, and the product feels considerably better on first contact.
It would also be the system claiming more than the record entails, which is the single thing this product has decided not to do. So the silence stays, and it is marked in the documents as correct, in capitals, specifically so that a future version of me does not come along and helpfully fix it.
This is a general problem with principled constraints. They are easy to hold while you remember why they exist and nearly impossible to hold afterwards, which means the actual engineering artefact is not the constraint but the note explaining it.
Where the distinction generalises
Outside software, the test is useful anywhere a product or a service claims a relationship with you. Ask of any such claim: what is the record that entails it?
An application that greets you by name has your name. The claim is small and it is honoured.
An application that says welcome back has a session flag. The claim is slightly larger than the record, but not offensively so.
An application that says it missed you has nothing at all, and is borrowing an emotion it has not earned.
A service that says we remember your preferences usually means it stored four settings, and the word remember is doing work the four settings cannot support.
None of these are scandals. They are ordinary, and they accumulate into a general erosion where users learn that the warmth in software is decorative, and stop reading it at all. Which is a shame, because the version where the warmth is backed by a record is genuinely valuable, and it is now indistinguishable from the version that is not.
The button tin, again
What my grandmother's tin had was continuity without persistence of state. Nothing in it recorded anything. The continuity lived in her, built from forty years of reaching in.
Software is in the opposite position. It has perfect persistence and is terrible at continuity, and it compensates by performing a familiarity it has not built. The interesting design problem, the one I think is actually worth a decade, is whether a system can hold the second kind honestly: accumulate a real record, make it available at the moment it helps, and never once claim to know you better than the record allows.
Saving is not remembering. Moving is not living. The gap between each pair is where most of the design work actually sits, and most products step over it without looking down.
Related reading
Latest Articles.
© Moc Mallen Studio
Thoughts, ideas, and perspectives on design, simplicity, and creative process.
