A non-technical detour: two short stories about a seamstress and a florist that accidentally explain why baselines, logs and root-cause analysis matter.

I read a lot of short fiction on my commute, and every so often a story describes an engineering habit better than most postmortems I've read. This week it happened twice, in two stories from the same free fiction site, TaleHour. Neither has a single computer in the plot that matters. Both are about people who survive an accusation because they kept boring records and refused to accept the first explanation.

Mild spoilers for the setup only. I won't give away the endings.

Story 1: the nightly snapshot

My Rival Tried to Frame Me by Planting a Single Thread follows Verna, who has spent forty years sewing and restoring gowns in a small town called Arbor Creek. She is restoring a 110-year-old wedding dress for the town's centennial when a newer shop owner, Kelsey, "discovers" a fresh tear in the side panel and announces, with great concern, that Verna's work is slipping.

It is a classic incident. Something is broken, there is a plausible culprit, and the person with the loudest voice has already written the root-cause summary.

What saves Verna is not cleverness. It's two habits she has had for years:

  • A daybook where she logs every stitch she puts into any garment.
  • A photograph of the work at the close of every working day, with the date in the corner.

When she checks, the last photo before the tear is dated Thursday, and the panel is whole. On Friday the dress left her custody overnight. That is the whole case in miniature: a known-good snapshot, a change window, and a chain of custody.

She then does what any good debugger does next. She gathers a sample from the suspected source and compares it under magnification with the thread found in the dress, at the same zoom, frame by frame. Same twist, same color cast.

What it teaches

  • Baselines are cheap until you need them. Verna's nightly photo costs her thirty seconds. Without it, the argument is her word against a confident newcomer's.
  • Logs should be written before anything goes wrong. A record created after an accusation looks like a defense. One created every day for decades looks like a fact.
  • Compare like with like. Same magnification, same light. Half of bad incident analysis is comparing things measured differently.

Story 2: two incidents, one shared dependency

I Trusted My Oldest Supplier for 30 Years is set in a flower shop in Port Blossom. The narrator, Geneva, has a bid riding on the town's Summer Festival when her stock starts dying overnight, leaves dusted with a white powder "like flour dusted on a countertop". The obvious suspect is Felicity, the slick new florist across the square who opened with a "clean, organic aesthetic" and has been taking Geneva's walk-in customers.

Then Geneva overhears Felicity on the phone in her back alley, furious that everything she buys arrives beautiful and dies in a day, and that she keeps being told it is her ventilation.

Two shops. Two outages. One upstream supplier.

Geneva's first instinct is to dismiss the thought "like a hot pan", because the supplier, Clarence, has left a ham on her porch every Christmas for years. Anyone who has ever defended a long-trusted vendor or library during an incident will recognize that flinch.

What it teaches

  • When two independent systems fail the same way, look at what they share. Rivalry made Felicity the obvious cause. The shared dependency was the better hypothesis.
  • Trust is not evidence. Thirty years of good service is a strong prior, not a proof.
  • Physical clues persist. The turning point involves a clay pot, and the fact that clay is porous. Artifacts remember their environment, much like a cached file or a stale config.

Why fiction is good for this

Postmortems tend to be written for the people who already understand the system. Stories are written for everyone, so they slow down at exactly the moments engineers skip: the social pressure to accept the first explanation, the reluctance to suspect a friendly dependency, the relief of finding the boring record that settles it.

Both stories are about ten minutes long and free to read without an account. If you want a break from your screen that still exercises the same muscles, the cozy and crafts collection on TaleHour is full of small, fair-play puzzles like these.

How do you keep baselines for systems nobody thinks to snapshot? I'd love to hear the low-tech versions in the comments.