The Wall Between Dev and Ops

For most of software's history, the two jobs from the last topic lived on two separate teams that barely talked. Developers built the software and then handed it off; a different operations team took that finished code and ran it. The handoff had a nickname that tells you everything about how well it worked: throwing it over the wall.

That wall — sometimes the teams really did sit in different buildings — is the problem DevOps was invented to knock down. To see why it needed knocking down, follow one Pageturn release across it, back when Maya and Sam worked on opposite sides.

Dev buildsthen hands it off

→

The wallhandoff, no shared ownership

→

Ops runsinherits the problems

The Handoff

In the old model, Maya's team would work for weeks or months, finish a batch of changes, and pass the result to Sam's team to deploy. Once the code was handed over, the developers considered their part done and moved on to the next batch. Running it in the real world was now somebody else's problem.

That sounds tidy on an org chart. The trouble is that the people who built the software — who knew exactly how it worked and why — were no longer the ones running it, and the people running it had never seen it being made.

The Wall of Confusion

This gap has a name: the wall of confusion. Operations was handed software they didn't fully understand and told to keep it alive. Developers got back vague reports that "it's broken in production" with no way to see what Sam was seeing. Neither side could view the whole journey from idea to live, so each only really understood their own half.

When something went wrong — and with this setup, something always went wrong — there was no shared picture to debug from. Just two teams, each holding one half of a story that only made sense whole.

The Blame Loop

So the blame began. Pageturn would crash after a release, and the conversation went in a circle. Sam: "Your code broke production." Maya: "But it works on my machine — it must be something your servers are doing." Each had evidence for their side and no way to see the other's, so the finger-pointing could run for days while the site stayed broken.

Notice that nobody here is the villain. Both are reasoning sensibly from the only half they can see. The wall didn't just slow things down; it actively turned two teammates into opponents.

Slow, Scary Releases

The wall had one more effect, and it shaped everything. Because every release was a risky, painful handoff that might trigger days of blame, teams did the logical thing: they released as rarely as possible. Changes piled up for months and then went out in one enormous batch.

That made things worse, not better. A giant release changes a hundred things at once, so when it breaks, no one can tell which of the hundred did it. Releases became rare, huge, all-hands, late-night events that everyone dreaded — the exact opposite of the small, calm, frequent changes you'll see DevOps aim for.