The electrician was standing in front of my panel.
Rows of switches. None labeled.
He had a marker. He put it back in his pocket.
I asked why.
“Because I’m not sure which does what. And a wrong label is more dangerous than no label.”
The next electrician would trust it blindly.
He walked away. The switches stayed blank.
I thought about that for a long time.

Then I recognized the pattern everywhere in software.

The 100% Coverage Lie

You’ve seen it. A codebase with 100% test coverage. Green badge in the README. The kind of number that gets cited in retros as a sign of maturity.

Then you read the tests.

def test_user_creation():
    user = User(name="test")
    assert user is not None

That test asserts existence, not behavior. It would pass if email validation was completely broken. It would pass if the function silently swallowed errors. But the badge says 100%.

The next developer who touches that code will trust it. They won’t write new tests because the coverage is already “complete.” They’ll ship on top of a foundation that was never solid.

That trust is the problem. Not the test. The trust.

Green CI, False Safety

The same pattern shows up in pipelines. A fast pipeline is not a correct pipeline.

Tests marked skip. Flaky tests quarantined into a folder nobody monitors. Integration tests replaced with mocks that stopped reflecting reality six months ago. The pipeline finishes in four minutes. Nobody asks why it used to take twelve.

Green means safe. Green means ship.

Until it doesn’t.

The failure, when it comes, won’t look like a test failure. It’ll look like a production incident. Because the signal said everything was fine, and everyone believed it.

Documentation That Used to Be Right

Third variant: documentation that was accurate when someone wrote it, and has been silently lying ever since.

The README says “run make setup.” The Makefile was deleted in a refactor eighteen months ago. The architecture diagram shows three services. There are now seven.

New engineers follow the docs. They spend hours debugging something that would be obvious if the docs simply said nothing. They assume the environment is wrong. They blame themselves. They don’t question the document because documents are authoritative.

An empty page is honest. An outdated one is a trap.

The Electrician Was Right

The common thread is trust at the point of handoff.

When a signal says “safe,” the next person stops investigating. They assume the work was done. They build on top of it. The wrong label doesn’t just fail to help: it actively prevents the right behavior, which is to look, to question, to verify.

No signal forces attention. A false signal removes it at exactly the wrong moment.

This is not a coverage methodology argument. It’s not about whether 100% is the right target. It’s about the discipline of only creating signals you can actually stand behind. If the signal doesn’t mean what people think it means, it is working against you.

What to Do About It

The fix is not more tooling. The fix is honesty about what your signals actually measure.

  • If your coverage number includes shallow, behavioral-free tests: say so. Add a comment. Add a section to your contributing guide.
  • If your CI skips the integration layer: make it visible. A failing step is more honest than a skipped one. A skipped step looks like a passing step from a distance.
  • If your documentation is out of date: delete the wrong parts. A gap is a prompt to investigate. Wrong content is a dead end someone else will walk into.

Mark things provisional. Write OUTDATED at the top of docs you cannot maintain right now. Add a comment above a shallow test: # smoke test only -- does not validate behavior. These are not admissions of failure. They are acts of respect toward whoever reads this next.

Silence is harder to misread than a wrong label.

The panel still has blank switches. Not because the electrician was lazy. Because he respected what the next person would do with that information.

He trusted the absence of a label more than he trusted a guess.

Hold your signals to the same standard. If you can’t be sure, leave it blank. The next developer deserves an honest question mark, not a false answer.