Systems Engineering · 2026-07-18
The Cost of Shared Assumptions
Database table prefixes exist for a reason. WordPress installs with a default prefix — <code>wp_</code> — and most sites never change it. For a developer writing queries against a single known installation, hardcoding that prefix is faster. It works. The site functions correctly. No one notices.
Until the site moves.
When a WordPress site migrates to a new environment, the database prefix sometimes changes. A well-executed migration accounts for this. A query written with a hardcoded <code>wp_</code> prefix does not. The site comes up, most things appear to work, and then something breaks in a way that's difficult to trace because the failure happens at the query level rather than the application level. The error message points at the symptom, not the assumption.
The developer who wrote the original query didn't make a mistake in any obvious sense. The query worked correctly in the environment it was written for. The assumption was invisible because it was never wrong — until the environment changed and made it wrong retroactively.
What Makes an Assumption Expensive
This is what makes shared assumptions expensive. They don't announce themselves. They accumulate silently, each one functioning correctly until the conditions that made them correct no longer exist.
A site built over several years by multiple developers may contain dozens of assumptions that no one documented because no one needed to — they were simply true. The upload path is always here. The prefix is always that. The API always returns results in this order. The plugin is always present.
Migrations expose them. So do major version upgrades. So does any change that shifts the environment enough to make previously stable assumptions unstable.
The failure mode is consistent: something breaks in a way that doesn't immediately point to a cause, because the cause is not in the code that failed — it's in the assumption the code was built on top of.
The Pattern Across Systems
This pattern appears far beyond WordPress. API integrations that assume a response structure that the vendor eventually changes. Build processes that assume a specific version of a dependency that gets updated. Scheduled jobs that assume a file path that gets reorganized. Cron processes that assume a specific execution environment that changes when a site moves hosts.
In each case, the assumption was reasonable when it was made. The environment that made it reasonable eventually changed. The assumption remained, invisible, until something broke.
Making Assumptions Explicit
The practical response isn't to distrust assumptions. It's to make them explicit.
A database prefix should be referenced from a configuration variable, not hardcoded. A path to an upload directory should be retrieved dynamically, not assumed. Any dependency on environmental state that could change should be named and documented, not left implicit.
This is more work at the time of writing. It is significantly less work than debugging a broken migration at 11pm because a query is referencing a table that no longer exists under that name.
The cost of a shared assumption is invisible until it isn't. By then, the cost is usually higher than the documentation would have been.