You have read every line of the service
and you still cannot explain
why that customer got two emails.
The answer is not in the code.
It is in a trigger on the table,
written in 2021,
by somebody who left in 2022,
which fires on update
and writes a row somewhere else.
It is in a scheduled job
on a machine nobody lists
in the architecture diagram,
because the diagram is about services
and that is a crontab.
It is in a rule at the edge
that rewrites one path
to a handler you retired.
It is in an automation
in the ticket system,
set up by an operations manager
who was being helpful,
which reopens anything
containing the word urgent.
It is in a spreadsheet
that finance maintains
and nobody in engineering has opened,
which decides who is exempt.
Every one of those
is a decision your system makes.
Only one of them
is in the thing you searched.
That is the whole problem.
Grep is not a search of the system.
It is a search of one artefact,
and it answers with confidence
in both cases,
whether the behaviour is absent
or simply somewhere it cannot look.
Watch what it costs.
A new person is told the folklore
in the second week,
because the folklore is the only
complete description there is.
Debugging turns into asking around,
so the ceiling on understanding
is whoever is still employed.
And a change that is correct
in every file you can read
breaks something
you were never given
a way to find.
So make it a rule
that behaviour has a home.
Logic lives where logic lives,
and if a thing genuinely must
run at the edge, or on a clock,
or inside somebody else's tool,
then the repository holds a list
of every place
that is allowed to act.
One file. Plain sentences.
Where it runs, what it touches,
who to ask.
The question to carry
into any system you inherit
is not what does this code do.
It is what else in this company
can change this row.
– Serguey Asael Shinder
