Silent overwrite is the worst collaboration failure
Aliases: lost update · last-write-wins · silent clobber
What it is
Silent overwrite (a lost update / last-write-wins with no notice) is a later write replacing an earlier one while the other person is not told. The UI shows neither a conflict nor “your draft was replaced.” The overwritten person still looks at their own words until a refresh, a reopen, or someone asking. It is worse than a visible conflict: a conflict at least keeps both sides on stage; a silent overwrite removes one side from the product, and history may not even keep a findable trace. Presence and choosable conflict exist so this step is never reached. “The later save succeeded” is not collaboration success.
Why it happens
Many stores replace a whole document or row; the newer timestamp wins. A local edit on a weak network or a long session gets the later stamp, so the winner is “who saved last,” not “whose change should stay.” The failure is silent because Save reports success—true for the later writer, a non-event for the earlier one. Detection is accidental: a sentence gone on reopen, or a colleague who never saw the line. With no event there is no moment to recover, and the undo stack points at one’s latest keystrokes, not at the overwritten version. Grain matters: a cell, a comment, a chapter can all be replaced as a block; coarser write units swallow more of the other person’s work in one silence.
Studying it
Two people save the same record after being offline or delayed. Compare: later write covers and both see success; later write covers but the earlier writer is told “your version is not current”; later write blocked until the delta is shown.
Independent variables: write unit (whole object / field), whether the earlier writer is notified, whether overwritten content enters history automatically. Dependent variables: delay until the earlier writer notices loss, loss grain (word / paragraph / whole), whether recovery is still possible.
If the lab lets people take turns saving while watching each other’s screens, silence is already broken. Isolate them, and treat “saved” feedback as evidence the earlier writer still believes their draft is live. If discovery happens only in the interview, the product never emitted an event. Do not excuse silent overwrite because history is comparable—being in history is not the same as knowing, then, that something was lost.
Where it stops holding
True field-level auto-merge (two people changing different fields) is not overwrite and should not alarm. An explicit “overwrite their draft” with preview and confirm is a visible dangerous act, not silence. Backup import and admin rollback replace a whole object and must notify everyone who has it open, or they are silent overwrite in other clothes. A read-only copy updated by someone else should prompt “content updated”—a refresh—so long as local unsaved edits are not thrown away.
Applying it
- Do not cover another person’s unmerged write with a newer whole-object timestamp and no prompt. At minimum keep the earlier write in history and tell that person “your changes did not enter the current draft.”
- Save-succeeded goes only to the writer whose bytes actually entered current. A save that would cover someone else opens the delta first.
- Write at field or paragraph grain, not a whole-object replace on every save.
- Verify: two isolated people each change an overlapping sentence, then save. If either sees Saved while the other’s sentence vanishes with no event, that is silent overwrite. Check whether the lost sentence can return to that person without a lucky hunt through history.