tmailrFor developers
The feature works. Nobody can tell.
31 July 2026 · 2 min read · TMailr
A crash gets fixed. Somebody sees a stack trace, a page goes red, an alert fires, and the thing gets attention because it is loud. The failures that survive for months are the ones that look like success.
Four from one system
Every one of these was found in this product, by testing, and every one had been running quietly since it was written.
- A message was accepted with a 250 and then dropped, because the recipient stopped being valid between one command and the next. The sender was told it was delivered.
- A daily audit reported problems and could not fail, because it never set an exit code. The alert it fed had nothing to react to.
- That alert was configured in the wrong section of the unit file, so it did not exist at all. The system logged a warning about it at every reload for weeks.
- A self-destruct option that deleted nothing. It set a flag, the purge only removed rows whose expiry had passed, and the messages stayed for the rest of the hour.
None of them threw. Every one of them had a green test somewhere nearby covering the part that worked.
The shape they share
In each case the system reported an outcome it had not achieved, and the report was the only thing anybody looked at. Nobody checks whether a 250 was followed by a row appearing. Nobody re-reads a unit file that has been in place for a month. Nobody asks an audit whether it is capable of failing.
The common ingredient is a gap between the claim and the thing claimed, with no test spanning it. Tests are usually written on one side or the other: the unit test proves the function, the smoke test proves the page loads. The claim in the middle goes unexamined because it is not code, it is a sentence.
How to find them
Read what the system says about itself and check each sentence separately. Not the code, the claims: the words on the page, the comment above the function, the name of the status field.
- Take the promise literally. Delete after the first message means the data is gone; go and look whether it is.
- Prove the alarm can fire. Break something on purpose and watch for the alert. An untested alarm is a decoration.
- Verify by observing behaviour, not by re-reading the code. The code is what convinced you it worked the first time.
- Be suspicious of anything that has never failed. It is either very good or has no way to tell you.
Why it is worth the time
A loud failure costs you an incident. A silent one costs you the assumption that everything else is fine, and you pay that cost on every decision made afterwards. The mail that was accepted and dropped is worse than the mail that was refused, because the refusal reaches somebody who can act and the acceptance reaches nobody at all.
Every one of the four above was a few lines to fix. The expensive part was that nothing was looking.
More on for developers
