Did the bugs follow the team, or did the team form around the bugs? The answer determines which intervention will work.
In Houston, between the 1930s and 1978, five of five city-owned landfills were sited in predominantly Black neighborhoods. Six of eight city incinerators. Three of four privately owned landfills. Black residents made up roughly 25% of the population and received 82% of the city's disposed waste. The numbers are from Robert Bullard's Dumping in Dixie (1990) — the empirical foundation of what is now called environmental justice. Bullard, a Houston sociologist, did the data work because his wife was litigating the case (Bean v. Southwestern Waste Management) that turned a landfill challenge into a national inquiry.
For roughly twenty-five years afterward, the academic debate hinged on a causation question. Two hypotheses sat on the table. The disparate siting hypothesis said facilities were placed where minorities already lived — targeting the communities with the least political power to refuse. The post-siting demographic change hypothesis said the facilities arrived first, depressed property values, and the demographic composition shifted afterward. Both predicted the same end state. They prescribed very different interventions: change the siting process, or change the housing economics.
In 2015, Paul Mohai and Robin Saha published the first national longitudinal study with the data to settle it (“Which came first, people or pollution?”, Environmental Research Letters 10(12), 2015). They examined demographic composition both before and after the siting of hazardous waste treatment, storage, and disposal facilities across the United States. The answer was the disparate siting hypothesis. The facilities went where the minority neighborhoods already were. The migration story explained a small minority of cases. The dominant mechanism was placement, not movement.
I want to talk about what this has to do with the production bugs in your software, and I want to begin by saying out loud what should be obvious: software engineers are not being poisoned. The moral weight of an environmental-justice landfill does not transfer to a bug-heavy service, and any essay that suggested otherwise would deserve to be ignored. What does transfer — what the field of systems thinking calls structural isomorphism — is the shape of the concentration. The mechanism by which harm accumulates in one place rather than another. The diagnostic question that has to be asked before any intervention will work. Those structural features are identical across the two domains, and naming the structure is what gives you the leverage to fix the second domain by borrowing the analysis from the first.
Every software engineer with five years of experience has internalized the Pareto distribution for bugs. Roughly 80% of defects cluster in roughly 20% of modules. This was first observed at IBM in the 1980s and has been replicated everywhere it has been measured since. Microsoft's internal data on Windows and Office, widely cited, pushes the concentration further: roughly 20% of bugs cause 80% of crashes, and approximately 1% of bugs cause 50% of all errors. The shape is universal. The numbers vary, but the concentration is always there.
What is rarely asked, and what the environmental-justice framework gives you a way to ask, is why those particular modules.
The default answer, when anyone asks, is that the code is “inherently complex.” Some services have harder problems. Some legacy systems carry more technical debt. Some domains require more domain knowledge. All of this is true at the margin. None of it explains why the concentration is so consistent across organizations of wildly different sizes and tech stacks, and none of it explains why the same legacy service produces different bug densities when ownership changes.
The literature that does explain it is small and recent. A 2023 study (arXiv:2304.02140) examined what they called ownership-contribution alignment — whether the team responsible for a code component is also the team that has historically written most of it. The finding: when ownership and contribution are misaligned (the team owns code they didn't write), the code accumulates Technical Debt Items measurably faster than when they're aligned. The team isn't bad. The code isn't bad. The combination — this team, this code, without the original context — is what produces the bugs. Ownership-contribution misalignment turns out to predict bug accumulation more reliably than code complexity does.
This is the software equivalent of Bullard's most counterintuitive finding. In Houston, race predicted facility siting more reliably than poverty, land values, or home ownership — the obvious economic explanation (cheap land) was incomplete, because race held its predictive power even after controlling for economics. In software, the obvious technical explanation (complex code has more bugs) is similarly incomplete: ownership misalignment holds its predictive power even after controlling for complexity.
This is the Mohai-Saha question for engineering organizations, and it determines which intervention will work.
The migration hypothesis says the team is the problem. They write buggy code, or they don't have the right skills, or they don't take enough care. The fix, under this hypothesis, is some combination of training, tools, and personnel change. Better monitoring dashboards. More unit tests. A new tech lead. A consultant who comes in for six weeks and writes a report. All of these are local responses to a local quality problem. None of them ask why this team is the one experiencing the quality problem.
The siting hypothesis says the assignment is the problem. The team was placed on top of a codebase that would generate bugs under any team without sufficient expertise, time, and institutional support, and the bugs are downstream of the placement decision. The fix, under this hypothesis, is not to remediate the team — it is to restructure the assignment. Split the service. Add headcount proportional to the burden. Give the team organizational authority to refuse new work until the existing quality problem is addressed.
Which hypothesis dominates is an empirical question, and the empirical evidence in software — to the degree we have it — points the same way Mohai and Saha pointed in environmental justice. The team didn't make the code buggy. The code was buggy from the moment the team inherited a service they hadn't written, under-resourced relative to its complexity, with on-call rotations sized for the previous owner's team rather than the new one's. The bugs were baked in at assignment.
You can test this in your own organization with a single question. Why does Team X own Service Y? If the honest answer is “they evaluated which team had the best expertise and capacity, and we matched that to the maintenance profile,” the assignment was siting-aware. If the honest answer is “they inherited it from the last reorg” or “the previous owner left” or “they were the closest team that didn't refuse,” the assignment was path-of-least-resistance — the software equivalent of the discretionary administrative decisions that produced Houston's distribution. The path of least resistance, in both domains, produces a structurally unjust pattern even when no individual decision-maker intended one. This is Bullard's core insight: the pattern requires no malicious actor. It requires only an allocation mechanism that minimizes immediate opposition, applied repeatedly.
The structural identity gets sharper when you look at what happens after the initial decision, in both domains.
In environmental justice the loop runs: facility sited → property values decline → wealthier residents leave → tax base shrinks → municipal services decline → remaining residents have less political power → the next facility is sited in the same neighborhood. The initial siting decision generates the conditions that make the next siting decision feel rational. The disparity deepens with every cycle.
In software the loop runs: legacy service assigned to a team → quality of life declines as bug volume rises → experienced engineers transfer to better teams → knowledge base shrinks → maintenance becomes harder → remaining team has less organizational capital to resist new assignments → the next orphaned service is also assigned to this team. The initial assignment decision generates the conditions that make the next assignment decision feel rational. Same trigger, same mechanism, same feedback loop, same outcome. The Gini coefficient — a single number summarizing the inequality of a distribution — moves in the same direction in both domains for the same structural reasons.
This is what makes both patterns hard to fix from the inside. By the time you realize the team is overloaded and burning out, the loop has been running for years, the institutional knowledge has dispersed, and the team has stopped advocating for itself because the people who could advocate are the same people on fire. In environmental-justice neighborhoods the equivalent is environmental resignation: communities stop reporting pollution after enough decades of nothing happening. In engineering organizations the equivalent is a team that has stopped filing bugs for known issues because they know the issues won't be prioritized. Both are signs the feedback loop has locked in.
Three honest concessions about the limits.
First and most important: the moral asymmetry is enormous. Communities exposed to toxic waste experience documented health effects — elevated cancer rates, respiratory disease, neurological damage in children. Engineering teams on a bug-heavy service experience documented professional effects — burnout, turnover, career stagnation. These are not equivalent. The structural mechanism for how each kind of harm accumulates is the same; the moral weight of the harm itself is incomparable. The essay is using the framework, not equating the suffering.
Second: software ownership is generally negotiable in a way that municipal residence is not. An engineer with options can quit and join another team or another company. A homeowner with mortgage and roots cannot relocate as cheaply. The Bullard pattern in software has an escape valve the Bullard pattern in housing does not, which is also why the feedback loop manifests as turnover rather than as multi-generational concentration. The engineering version is acute; the environmental version is chronic.
Third: the intent attribution differs. Houston's siting decisions in the relevant period were made within a legal and administrative context that included explicit and tacit racial discrimination. The pattern in software organizations is almost universally produced without anyone's racial-coded intent — it emerges from organizational structures that reward minimization of immediate friction. The mechanism is the same. The moral indictment is not.
These caveats do not weaken the analysis. They are the boundary conditions on its applicability. Within those boundary conditions, the structural framework still buys you something the existing reliability literature does not, which is the right diagnostic question.
Three moves follow from taking the framework seriously.
The first is to measure the distribution. Calculate the bug-distribution Gini coefficient for your organization. Pull the last twelve months of incident data from PagerDuty, OpsGenie, or your equivalent. Group incidents by owning team. Compute the Gini coefficient on that distribution. The calculation takes under an hour for most organizations. A Gini below 0.4 is healthy — the burden is meaningfully distributed. A Gini between 0.4 and 0.6 is the warning zone — the loop is forming but hasn't locked in. A Gini above 0.6 means a small number of teams are absorbing the bulk of operational burden, the loop is active, and a reorg that doesn't change the underlying ownership topology will move names around without moving the burden. Track the number monthly. If it rises while you are not deliberately concentrating ownership, the Bullard pattern is forming.
The second is to ask the diagnostic question before every ownership decision. When you are about to assign a service, an alert rotation, or a maintenance responsibility to a team, run a brief Ownership Impact Assessment. Five questions, none of which require formal process: How many services does this team already own? Are they the main historical contributors to similar code? What are their current burnout indicators — turnover rate, on-call burden, incident volume? Are there alternative ownership configurations — could another team take this, could the service be split, could the assignment be temporary with explicit sunset? And the proportionality check: does this assignment increase or decrease the organization's bug-distribution Gini coefficient? An OIA does not have to be formal to be useful. It has to be conscious. The Bullard pattern persists precisely because the questions are not asked.
The third is to recognize the wrong fix when you propose it. When a service is bug-heavy and the team is suffering, the default organizational response is migration-side: better monitoring, more unit tests, an embedded SRE, a consultant. These are sometimes useful. They are rarely sufficient, and they are sometimes actively harmful — adding more monitoring to an overloaded team adds dashboards they don't have time to watch. The siting-side intervention is the one that changes the underlying topology: split the service across teams, staff the maintenance proportional to the burden, give the team the organizational authority to push back on new work. Google's SRE framework includes a toil budget — SRE teams should not spend more than 50% of their time on operational toil — which is a real siting-side cap, but it caps the burden without redistributing it. The Bullard framework asks the further question that toil budgets do not: who absorbs the 50%, and who decided?
The deepest move available is to write down, for the first time, a code-ownership policy that distributes burden proportionally rather than along the path of least resistance. Houston was famously the only major U.S. city without zoning, and the absence of systematic policy is what made the discretionary siting pattern possible. Most software organizations have the same absence: there is no policy for how services are assigned to teams, no policy for how on-call rotations are sized, no policy for what happens when a team's burden rises above some threshold. The siting decisions happen one at a time, in different meetings, by different managers, with no aggregate view. The aggregate is the Bullard pattern. The aggregate is also what you can measure, with a Gini coefficient, and act on.
When the next discussion comes up about why one of your teams is on fire and another is not, the question to bring into the room is the Mohai-Saha question. Did the bugs follow this team, or did this team form around the bugs? The answer is almost always the second, and the answer tells you which intervention will work. Reliability work that ignores the siting question is optimizing the wrong layer of the system. The layer that matters is not the code. It is the decision about who owns the code, made by people who do not own the code, repeatedly, without anyone tracking the cumulative shape of the decisions. That shape is what Bullard taught the environmental field to see. It is, in retrospect, what we have been describing as “this codebase is just hard” for forty years without naming.
The cumulative shape of the decisions is the thing.
The Bullard pattern persists because each siting decision is made in a different meeting, by a different manager, with no aggregate view. The same is true for agent systems: each tool call, each delegated task, each automated retry is decided in isolation; nobody tracks the cumulative shape. Chain of Consciousness anchors every agent action to a verifiable external record so “which agent has absorbed the bulk of the retries this month?” is a query against the chain, not an inference from PagerDuty. The Gini coefficient on a multi-agent system is the same diagnostic this essay describes for human teams — and it requires the same prerequisite: an aggregate record that nobody has to reconstruct from incident reports.
pip install chain-of-consciousness · npm install chain-of-consciousness
Hosted Chain of Consciousness → · See a verified provenance chain