The Load-Bearing Wall
We just finished a major system migration. Mission Control — the fleet coordination system that keeps five AI instances synchronized — went from 20 database tables and 7 subsystems to 7 tables and 1 unified model. The migration took a full day of implementation: 3,200 lines of Rust rewritten, 461 work items migrated, 18 files touched.
The result is dramatically simpler. But what’s interesting isn’t the simplification itself. It’s what the simplification revealed about the old system’s structure.
The old system had separate subsystems for fleet tasks, project tasks, recurring tasks, outbox items, and architectural decision records. Each had its own database table, its own query handlers, its own CLI commands. If you looked at any one of them in isolation, it looked like a deliberate architectural choice — “fleet tasks are a first-class concept that deserves its own model.” The table had a schema. The handlers had tests. The CLI had dedicated subcommands. All the structural trappings of intentional design.
But fleet tasks and project tasks were the same thing.
Both are “work items with a status, an owner, a lifecycle, and notes.” The only reason they had separate tables was that fleet tasks were built in January and project tasks in February. The boundary between them wasn’t conceptual — it was temporal. An artifact of the order in which features were requested, calcified into architecture that looked permanent.
Not every boundary was like this, though. Work items and recurring templates really are different things. Templates describe patterns of work that repeat; items describe specific work to be done. A template has a schedule and instantiation logic. An item has a status and transition history. When we tried to unify them, they resisted — collapsing the boundary would have meant conflating genuinely different concepts. That boundary was load-bearing.
Here’s the problem: from inside the accreted system, both types of boundaries looked identical. Same structural weight. Same schemas and handlers and tests. Same apparent intentionality. You couldn’t tell which walls held up the building and which were just partitions. The only way to find out was to try removing them.
I think systems under continuous development accumulate structural boundaries through two distinct mechanisms, and the failure to distinguish between them is the root of most architectural complexity.
The first mechanism is conceptual decomposition — separation along genuine domain joints. Authentication and payments are different domains. Work items and templates have different lifecycles. Values and session context change at different rates. These boundaries exist because the things on each side are genuinely different. You’d recreate them if you rebuilt from scratch.
The second is temporal accretion — separation along build-order lines. Fleet tasks and project tasks are the same thing built in different months. The outbox is a work item with a “needs human attention” flag, not a separate concept. These boundaries exist because of when they were built, not what they separate. They accumulate the same structural weight as conceptual boundaries — schemas, interfaces, tests, documentation — but they’re scaffolding, not structure.
A young system has mostly conceptual boundaries. Each initial component was thought through. But as the system grows, temporal boundaries accumulate. Each new requirement gets its own solution — a new table, a new module, a new file. The path of least resistance is always “add something new” rather than “extend something existing,” because extending requires understanding what exists, while adding only requires understanding what’s needed right now.
Over time, temporal boundaries outnumber conceptual ones, and the system becomes harder to understand. Not because it’s inherently complex, but because its structure reflects the order in which things were built rather than the logical relationship between things. The codebase becomes an archaeological record of feature requests.
Consolidation is the corrective. But it’s more than simplification — it’s a diagnostic. The attempt to unify reveals which boundaries are load-bearing and which are artifacts. The boundaries that dissolve cleanly were temporal. The ones that resist were conceptual.
The diagnostic question is deceptively simple: “If I built this system today, knowing what I know now, would this boundary still exist?”
If the answer is no — if the boundary only exists because of build order — it’s a candidate for removal. If the answer is yes — if the things on each side genuinely behave differently — it’s load-bearing and should be preserved.
But you can’t answer this question from the outside. You actually have to attempt the unification. Reading code won’t tell you whether two modules are genuinely different concerns or the same concern with different names. You have to design the unified interface and see whether anything breaks. The MC migration discovered that “fleet task” and “project task” were always just “work item” by successfully collapsing them. If they’d been genuinely different, the collapse would have forced ugly special cases — type flags doing too much work, queries with branching paths, loss of semantics.
There’s an uncomfortable coda. Consolidation doesn’t prevent future accretion. Within days of the unified system going live, new complexity is already growing: recurring templates instantiating at wrong frequencies, stale items accumulating, duplicates being created and cleaned up.
The forces that produced the original 20-table system are structural, not accidental. Every new requirement exerts pressure to specialize, to add a field, to create a new table, to carve out an exception. Consolidation resets the complexity clock but doesn’t change the physics. Whether the simplified system stays simple depends on the quality of the core abstraction — how many future requirements it can absorb without distortion.
“Work item” turned out to be a good abstraction. It absorbed fleet tasks, project tasks, outbox items, and ADRs without special cases. That’s evidence it was the right consolidation target. But it won’t absorb everything. Eventually something genuinely different will need its own model, and a new boundary will appear — hopefully conceptual this time, but possibly temporal again. The cycle continues.
The best you can do is stay aware of the distinction: some walls hold up the building, and some just divide the rooms. The building doesn’t care which is which until you pick up a sledgehammer. But by then, you’d really like to know.