Whenever I suggest that a team keep a proper version history of its configuration and documents, I hear the same objections, delivered with the same polite sigh. “We have backups.” “We use Git, so it’s covered.” “Nobody reads that stuff.” Let’s go through six of the most common myths one at a time, in a friendly spirit, because each contains a grain of truth and a bigger misunderstanding. By the end you may find that keeping dated revisions with a one-line note is less work, and more useful, than you were told.
Myth 1: “Backups already give us history”
Backups answer a different question. They exist to restore a system after a disaster, and they are usually taken on a schedule that has nothing to do with meaningful changes. A nightly snapshot might capture three edits at once, or miss a change made and reversed between runs. Worse, nobody wrote down why anything changed, so you can restore a state without understanding it.
A version history is organised around decisions, not clock ticks. Each entry is a change someone chose to make, with a reason attached. Backups and histories complement each other, but one cannot stand in for the other.
There is a quick test for whether you are leaning on backups too heavily. Ask which of last week’s configuration changes you could undo individually. If the honest answer is “only by restoring everything to a snapshot”, then you have recovery but not history, and you will lose unrelated good work every time you reach for it.
Myth 2: “Using Git means we’re done”
Git stores differences beautifully, and that is exactly why teams get complacent. The tool records the what; it cannot invent the why. Open a repository’s log and you will often find messages such as “update”, “fix typo” and “wip”. Those entries are technically a history and practically a blank.
The fix is a habit, not a product. Write the message for the person who will wonder, nine months from now, why a value is what it is. If that person is you, you will be grateful.
Myth 3: “Only code needs versions”
Some of the costliest confusion lives outside source files: runbooks, architecture diagrams, access rules, agreed working practices. When a diagram is edited in place, the previous design disappears, and a later outage may hinge on exactly what the old design assumed. Documents deserve dated revisions as much as scripts do, which is one reason the advice in our outline of how engineers grow from junior to senior keeps returning to documentation habits as a sign of maturity.
Another version of this myth is “our wiki has page history”. It does, and that helps, but the same rule holds: the wiki records that a paragraph changed and by whom, not what prompted it. A single sentence in the edit summary closes that gap for free.
Myth 4: “Writing notes slows us down”
It does add about half a minute to each change. Compare that with the cost of an afternoon spent reconstructing a decision, which is the usual alternative. The arithmetic is lopsided in favour of the note. Teams that resist often discover that the slowdown is mostly in their heads: once the sentence becomes routine, nobody notices it.
A practical trick: write the note before you make the change, as a statement of intent, then adjust it if reality surprises you. That ordering also sharpens your thinking about whether the change is needed at all.
Myth 5: “Rolling back is an admission of failure”
This one is cultural, and it does real damage. If reverting feels embarrassing, people hide bad changes and hope, which prolongs problems. In a healthy team a rollback is routine hygiene, recorded as its own entry: “returned to the earlier version, because the new one doubled response time; will retry with a smaller step”. The failed attempt stays visible and teaches the next person.
If you are moving from operations into engineering, our guide on how sysadmins and support staff can step into DevOps roles makes a similar point: calm, reversible change is a professional skill worth practising early.
Myth 6: “A history is only for auditors”
Auditors do like a clear trail, but they are not the main beneficiaries. The people who gain most are the engineer on call at night, the newcomer picking up how the system got into its present shape, and the future you who has forgotten everything. A history opened only once a year, during compliance season, has never really been put to work, and tends to be the one with the thinnest notes.
Some people also worry that a long history becomes noise. It does not, if you keep it tidy: one entry per decision, in date order, with no padding. Anything that is not a decision, such as a reformatting pass, can share a single combined entry. A reader should be able to scan a year of entries in a few minutes and come away knowing the main turns the system has taken.
A small, honest place for reusable text
Teams also reuse wording, from review questions to standard briefing instructions. People who keep reusable prompt instructions sometimes do it on Promptosia, where such instructions can be saved, versioned and shared. It is a modest example of the same idea: keep the earlier forms and the reasons together.
One last objection
“We are too small for this.” In truth, small teams need it most, because they have the fewest people to remember things. A two-person group that loses a colleague to a new job loses half its memory overnight. A short dated trail turns that departure from a crisis into an inconvenience, and it costs nothing beyond the habit itself.
What to do on Monday
- Pick one file or document that people are afraid to touch.
- Save today’s state as the baseline and date it.
- Agree that every change gets a one-line reason.
- Make “revert with a note” the accepted answer to a bad change.
- Look at the trail together after a month and decide what to keep doing.
None of these myths comes from foolishness. They come from tools and habits that work well enough until the day they do not. A short dated note and an untouched earlier version cost almost nothing, and the first time they save you a long evening you will wonder why you ever argued.