The Wall Between Dev and Ops

To understand why DevOps exists, you have to understand the problem it was invented to solve. That problem had a name long before “DevOps” did: the wall. For decades, building software and running software were two separate jobs, done by two separate teams, with a wall between them. The wall is gone in name at the best companies and very much alive in practice at many others — so it’s worth seeing exactly how it was built, because every brick is an incentive, and incentives don’t disappear just because you rename the team.

Two teams, two goals, one system

In the old model, a Development team wrote features and a separate Operations team ran them in production. On paper, a clean division of labour. In practice, the two teams were measured on opposite things.

   DEVELOPMENT                         OPERATIONS
   ────────────                        ──────────
   goal:    ship new features          goal:    keep the system up
   reward:  velocity, new stuff        reward:  uptime, no surprises
   change is:  the job                 change is:  the threat

Look at the bottom row. To a developer, a change is the work — shipping it is how you create value and how you’re judged. To an operator, a change is the single most likely cause of the next outage — because most outages are triggered by a change, not by a server spontaneously failing. So the two teams, looking at the very same deployment, see opposite things: Dev sees progress, Ops sees risk.

This isn’t because either team is foolish or lazy. Each is behaving rationally given how it’s measured. That’s the crucial insight: the dysfunction is structural, not personal. You can replace every person on both teams and the conflict returns, because the conflict lives in the incentives, not the people.

Conway’s Law, lurking

Conway’s Law, paraphrased: organisations design systems that mirror their communication structure. Split the people into Dev and Ops and you’ll get software with a hard, brittle seam exactly where the handoff happens — a release process nobody fully owns. The org chart leaks into the architecture.

Throw it over the wall

Here is the handoff that gave the wall its name. Dev finishes a release and “throws it over the wall” to Ops to deploy and run:

        DEV side          │  THE WALL  │         OPS side
   ─────────────────────  │            │  ─────────────────────────
   "It works on my        │   ████     │   "It's broken in prod and
    machine. Shipping it." │   ████     │    I have no idea why."
        ──── release ─────────────────────────────────────>
                          │   ████     │
        <───── page at 2 a.m. ──── "your release broke" ──

Watch what crosses the wall: a build artifact, a wiki page of deploy steps, and a prayer. What does not cross the wall is context — why the change was made, what it assumes about the environment, how to tell if it’s healthy, what to do when it isn’t. The person who has that context (the developer) is not the person on the pager (the operator). So when it breaks:

• Ops can’t fix it — they didn’t write it and don’t know its internals.
• Dev can’t see it — they have no access to production and no visibility into what it’s doing.
• Nobody owns it — and so the incident drags while the two teams negotiate across the wall.

Every step of that handoff is manual and human: someone copies files, someone edits a config by hand, someone follows a runbook from memory, someone decides whether it’s healthy by squinting at a log. Manual, error-prone steps — exactly the things this book is about removing.

The classic line

“It works on my machine” is the wall in five words. The developer’s machine and the production server differ — different OS, different library versions, different config, different data — so code that passes on one fails on the other. (This specific failure is why containers exist: ship the environment with the code so “my machine” and “production” are the same machine.)

The cost of the wall

The wall doesn’t just cause individual outages. It warps how the whole organisation ships:

• Releases get rarer and bigger. Because deploys are scary and painful, teams batch up months of changes into one giant release to “get it over with.” This is exactly backwards, as the next page on feedback loops shows: big rare releases are more dangerous, not less.
• Recovery is slow. With Dev and Ops separated, diagnosing a failure means a cross-team relay race while users wait.
• Blame flows along the wall. “Dev shipped a bug” / “Ops misconfigured the server.” Energy goes into protecting your side instead of fixing the system. (Why blame is corrosive is the heart of CALMS.)

How DevOps dissolves the wall

DevOps is the response to all of this. It is not a tool you install or a team you hire — it’s a change to the structure that built the wall. Two moves do most of the work:

1. Shared ownership. “You build it, you run it.” The team that writes a service is also on the pager for it in production. This single change re-aligns the incentives that created the wall: now the same people feel both the pull to ship and the pain of an outage, so they’re motivated to ship safely. The opposing goals collapse into one goal — a healthy change in production.

2. Automate the handoff. Replace the manual, over-the-wall steps with an automated path from commit to production: build, test, package, and deploy by machine, the same way every time. There’s no wall to throw things over when there’s a pipeline running through where the wall used to be.

   BEFORE                         AFTER (DevOps)
   ──────                         ──────────────
   Dev ──wall──> Ops              one team owns commit ──> production
   manual handoff                 automated pipeline
   change = conflict              change = the shared, safe routine

Everything else in this book — containers, CI/CD, infrastructure as code, observability — is machinery for one or both of those moves: giving a single team the power to ship and run safely, and replacing the manual handoff with automation.

The thread: the wall was the manual handoff — files copied by hand, configs edited from memory, a runbook followed under pressure at 2 a.m. DevOps removes those steps by automating the path to production and putting the people who understand the code in charge of running it. That’s what makes production safer: fewer hands fumbling in the dark, and the right hands on the controls.

It actually happened — Knight Capital’s $440M deploy (2012)

On 1 August 2012, the trading firm Knight Capital pushed new code to its automated order routers. The deploy was done by hand across eight servers — and one server was missed. To make it worse, the release reused an old feature flag that, on the un-updated server, switched on long-dead “Power Peg” test code. The instant markets opened, that server began firing millions of unintended orders. In roughly 45 minutes Knight lost about $440 million — more than the cash the company had on hand — and was effectively destroyed. Nearly every ingredient is the wall: a manual deploy with no automated check that all eight servers matched, context that lived in one engineer’s head, and no fast, safe rollback. An automated, all-or-nothing deploy that refused to proceed unless every server was identical would have made the whole disaster impossible.

Check your understanding

1. Why do Development and Operations want opposite things? Phrase it in terms of how each team is measured, not in terms of attitude.
2. Why is it more accurate to call the dev-vs-ops conflict structural rather than blaming either team?
3. What “throws over the wall” in a release handoff, and — more importantly — what fails to cross with it? Why does that make outages drag?
4. Explain “it works on my machine” as an instance of the wall. Which later technology directly attacks this failure?
5. Name the two structural moves by which DevOps dissolves the wall, and say which incentive each one fixes.

Show answers

1. Dev is measured on velocity (shipping change is the work), Ops is measured on uptime (change is the most likely cause of the next outage, since most outages are triggered by a change). The same deploy that scores Dev points is the thing that threatens Ops’s score — so the metrics, not attitudes, put them at odds.
2. Because the dysfunction lives in the incentives, not the people. You can replace every individual on both teams and the conflict returns, since each side is behaving rationally given how it’s measured. Blaming people misses that the structure manufactures the conflict.
3. A build artifact, a wiki of deploy steps, and a prayer cross the wall — but context does not: why the change was made, what it assumes about the environment, how to tell if it’s healthy. So when it breaks, Ops can’t fix it (didn’t write it), Dev can’t see it (no prod access), and nobody owns it — the incident drags while the teams negotiate across the wall.
4. The developer’s machine and the production server differ (OS, library versions, config, data), so code passing on one fails on the other — the wall in five words. Containers attack it directly: ship the environment with the code so “my machine” and “production” are the same machine.
5. (1) Shared ownership (“you build it, you run it”) — fixes the opposing-goals incentive by making one team feel both the pull to ship and the pain of an outage. (2) Automate the handoff — replaces the manual over-the-wall steps with a pipeline from commit to prod, so there’s no wall to throw things over.