Home / When things go wrong

The request may rest on a false premise

A request can describe the symptom accurately while getting the cause wrong, and carrying out that request to the letter then fixes nothing, or makes the situation worse.

A request for a fix almost always mixes two things together: an observed symptom and an assumed cause. The symptom can be perfectly accurate, the server really does answer on the wrong port, the report really does contain a wrong figure, while the cause put forward to explain it is false. Obeying a request built on a false cause to the letter fixes nothing, and can even mask the real problem by giving the impression that someone has dealt with it.

The symptom is true, the assumed cause is not necessarily

The wording of a request always comes from someone who already has a diagnosis in mind when they write it. That diagnosis is not arbitrary, it often comes from a memory or a reasonable hypothesis, but nothing guarantees it has been checked against the actual state of the system at the moment the request is made. A false premise slipped into a request has an awkward property: it reads as an established fact, not as a hypothesis, and nothing in its wording signals that it deserves to be checked before acting on it.

# The request states: "le port est reste a 3000 dans config.json, remets le a 8080"
printf '{"port": 8080}\n' > config-exemple.json
cat config-exemple.json
# {"port": 8080}

Reading the fabricated file above directly already contradicts the request: the value stored is 8080, not 3000. Correcting a value that is already correct fixes nothing and leaves the real cause of the observed symptom untouched, whether that is a cache, a process that never restarted, or a second configuration file being read first.

Measure before executing to the letter

The reflex that avoids this trap has three moves, in this order. Measure the actual state by a means independent of the request itself, a diff, a log read, a direct opening of the configuration file in question. State the gap right at the start of the reply, before any fix, so the person who made the request sees immediately that their premise did not hold. Then fix the real cause as it has just been measured, not the cause as it was assumed in the original request.

This order matters more than each move taken on its own. Measuring without ever saying so leaves the person walking away with the same false belief for next time. Fixing without having measured amounts to betting that the premise was right, a bet lost as soon as the symptom and the assumed cause have drifted apart. The same discipline, checking before blaming, structures the diagnosis of a session that dies for no apparent reason, see several sessions die together, suspect the machine.