Half my bugs came from asking: what does this date even mean?
One column was doing two jobs and defaulting silently to today. The most expensive bugs aren't crashes, they're fields that quietly mean two things and pass every test.
A surprising share of the nastiest bugs I’ve chased didn’t come from code at all. They came from one question nobody had asked of an old column: what does this date actually mean?
In one system, a field I’ll call delivery_date was quietly doing two completely different jobs. Sometimes it meant the day a job was scheduled. Sometimes it meant the day the job was actually delivered. There was no separate completion timestamp at all, so when one was missing it defaulted, silently, to today. The column had a name that implied one clear thing and a reality that was at least three things, depending on which code path wrote it.
A field that means two things passes every test
Here’s why this category of bug is so expensive: nothing crashes. The column holds a valid date. Every insert succeeds. Every test that checks “is there a date here” passes. The app is green. And meanwhile every report that assumes delivery_date means delivered is quietly wrong, every invoice that keys off it is subtly off, and the numbers drift in a way no stack trace will ever point you to.
I traced a whole pile of reporting and invoicing weirdness back to that one fuzzy field. Not a logic error. A semantics error. The code did exactly what it said. What it said just meant two things.
There was a second sin stacked on the first. The column stored a bare date when the business actually cared about the time of day. Two events on the same afternoon were indistinguishable, so any ordering or deadline logic built on it was guessing.
The most expensive bugs aren’t crashes. They’re columns that quietly mean two things, pass every test, and corrupt every report.
Pin the meaning before you trust the field
The fix in the schema was easy once the meaning was clear: split the two ideas into two fields, give “delivered” a real timestamp with the precision the business needs, and stop letting anything default to today. The hard part was never the migration. It was admitting I’d trusted a name instead of a definition.
So now, before I build anything on top of an inherited field, I make someone say out loud, in one sentence, exactly what it represents and at what precision:
- What real-world event does this record? Scheduled, started, completed: pick one, and name the field that.
- What precision does the business actually need? A date, or a moment in time? Guess wrong and you can’t recover it later.
- What happens when it’s unknown? “Defaults to today” is a lie the database tells on your behalf. Prefer an honest null.
A column name is a promise. Half my worst bugs were a name making a promise the data never kept. The cheapest debugging tool I own is still a sentence: what does this field mean, exactly, and at what precision? Ask it before you trust the answer, not after the invoices go out wrong.