Dave Farley tells a story about an organisation that took months to ship a release. Staged, layered, careful. While someone walked him through the process, he asked what happens when production breaks and a fix has to go out now.
"Oh, we can do a type seven release in under an hour."
So why not run every release as a type seven?
"We couldn't possibly do that. The risk is too high."
Type seven was their name for skipping every check the normal process existed to run, shipping the diff, and hoping. That organisation kept two paths to production: one so slow nobody could learn from it, and one so dangerous they saved it for emergencies.
Your observability has a type seven too.
You know the shape of it. Production is misbehaving, your dashboards answer none of the questions you have, so someone adds a log line and ships it. Waits for the deploy. Reads the output. Adds another log line. Or flips debug logging on across a service for twenty minutes and flips it off before the bill arrives. Or attaches a debugger to a live process and holds their breath.
Nobody files that under "the normal process failed". It goes under incident response, where uncomfortable things go to be forgiven.
The talk this story comes from is worth watching in full:
Organisations that get this right never need a type seven. Releasing is already cheap and fast enough that even a real emergency uses the normal path, with the safety still in it. Fast and safe stop being a trade-off. Two paths exist when you plan your way through a system that only yields to learning.
Support asks a year after the payment: "Why did the customer receive €117? And which card did we charge?"
A supportable system answers that with one query. If answering means trawling archived logs, guessing what the exchange rate was that day, and hoping nobody edited the payment method since, you don't have a supportable system.
Record the decision at the point you make it, and never destroy the data it points to.
There’s a major disconnect in AI-assisted development right now. Most of the conversation assumes you’re building something new, or working from the kind of clean, stable foundation that barely exists in real engineering teams.
The reality is that most engineering teams live in legacy systems under high load, with god classes, global singletons, and console.log as observability. The kind of code where every change is a gamble.
This post shows what happens when you apply fn(args, deps) and autotel to those codebases. fn(args, deps) creates the seam for safe change; production telemetry captures the behavioural record that survives when every other spec has decayed.
To prove the point, we’ll do this in plain JavaScript, not TypeScript.
Engineers are responsible for designing and building complex systems that are expected to perform optimally under different conditions. However, without a deep understanding of how these systems behave, they risk making assumptions that can result in inefficiencies or even system failures.
In this post, we'll discuss why understanding a system like a doctor helping a patient is essential for engineers and by taking a proactive and data-driven approach, engineers can ensure that their systems are performing optimally and can make informed decisions that result in improved performance and reliability.
