The Most Expensive Data Is the Data That Changes Nothing

Most conversations about data quality focus on whether the data is accurate. Fewer focus on whether the data was worth collecting in the first place. In practice, I've found the second question costs more than the first.

The field nobody looks at

Every pipeline I've worked on has fields like this: collected on schedule, validated on schedule, stored on schedule — and never once opened in a dashboard, never once cited in a decision, never once missed when a run failed. The field isn't wrong. It's just inert. And inert data isn't free: it still has to be crawled, parsed, validated, stored and maintained, which means every unused field is a small, recurring tax that nobody notices because the invoice never arrives as a single number.

That's the pattern behind one of the changes I've made repeatedly in practice: not fixing broken data, but questioning whether a field earns the cost of collecting it at all. See the Too Much Data → Less Noise case for a concrete version of this.

Why this is easy to miss

Broken data announces itself — a dashboard breaks, a report looks wrong, someone complains. Data that changes nothing never announces itself, because nothing downstream depends on it closely enough to notice its absence. That asymmetry is exactly why it survives: fixing what's broken is urgent, but retiring what's unused is only ever important, and important-but-not-urgent work loses by default unless someone deliberately asks the question.

The question I actually ask

Before adding a field, or defending an existing one, I ask what decision it changes. Not what it describes — what it changes. If I can't name the decision, more of that data won't make anything better; it'll just make the pipeline slower and the validation layer more brittle. This is the same instinct behind starting with the decision, not the dataset, and it shows up again in why more data can make a product worse, not better.