DevOps: Culture, Automation, and an Old Argument Reopened

DevOpsDevOps is usually introduced as a set of tools — pipelines, containers, infrastructure-as-code — but it started as a cultural argument about who is responsible for what happens after code is written, and the tools followed from that argument rather than the other way round. It also sits at an interesting angle to the rest of this series: it isn't a project-planning methodology like Scrum or Waterfall, it's a proposed answer to a specific organisational failure mode that any methodology can suffer from — and one with a real, if contested, claim to being older than its own name.

The Problem It Names

BeforeBefore "DevOps" existed as a word, a familiar pattern already existed as a complaint: development teams are measured on shipping change, operations teams are measured on system stability, and those two incentives point in opposite directions. A developer who ships fast and an operator who keeps things running by changing as little as possible are each doing their job correctly, and the two jobs correctly done still produce a slow, blame-heavy release process — a wall between two teams who each optimise locally and fight at every handoff. DevOps names that wall as the actual problem, rather than treating the friction at release time as an unavoidable cost of doing business.

Real Origins, Not a Marketing Term

TheThe name has a specific, dateable origin. Patrick Debois, a consultant who had lived the dev/ops divide firsthand on a large data-centre migration, watched a 2009 conference talk by John Allspaw and Paul Hammond of Flickr titled "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr," which described deliberately dissolving the wall between development and operations rather than managing around it¹. Energised by it, Debois organised a small gathering of developers and system administrators in Ghent, Belgium in October 2009 under the name DevOpsDays — the event, and the contraction of its name, is the origin of the term².

The framework most commonly used to describe what DevOps actually consists of — beyond "developers and operators getting along" — is the CAMS model: Culture, Automation, Measurement, Sharing, coined by Damon Edwards and John Willis at the first US DevOpsDays event in Mountain View in 2010. Jez Humble later added a fifth letter, Lean, producing the more commonly cited CALMS³:

Letter	Principle
Culture	Shared ownership and blameless collaboration between development and operations, not a formal reorganisation alone.
Automation	Build, test, and deployment pipelines automated end to end, removing manual, error-prone handoffs — the practical overlap with CI/CD.
Lean	The same waste-elimination and flow thinking as Lean Software Development, applied to the release process itself.
Measurement	Real production data — deployment frequency, lead time, failure rate, recovery time — used to know whether the process is actually improving, not assumed.
Sharing	Knowledge and tooling shared openly across the former dev/ops boundary rather than siloed inside either team.

An Old Argument, Reopened

It'sIt's a fair observation — and worth taking seriously rather than dismissing — that much of what DevOps formalises is not new. Automated builds, configuration management, and close collaboration between the people who write software and the people who run it all existed well before 2009, under other names, in other eras of computing where the person who wrote the code and the person who operated the machine were sometimes the same person, or sat in the same room. What DevOps did was give a name, a movement, and a specific set of practices to a problem that industrial-era specialisation had itself created: as development and operations became separately staffed, separately measured, and separately incentivised — a genuine organisational advance in some respects — the coordination cost between them became large enough to need its own explicit fix. Read this way, DevOps is less an invention of new technique and more a correction applied to a division of labour that had drifted too far, using automation that had, by 2009, become practical at a scale it wasn't before. Whether that counts as "reinventing" older practice or as a genuinely new synthesis of old ideas plus new automation capability is a reasonable question to sit with, not one this page claims to settle — but it's a more interesting question than treating DevOps as having appeared from nowhere.

Where DevOps Sits Relative to Everything Else in This Series

DevOpsDevOps is orthogonal to the methodology choice, not a competitor to it: a team can run Scrum, Kanban, or a Waterfall-staged process and still have, or lack, a DevOps culture, because the dev/ops split it addresses can exist inside any of them. In practice it's most naturally paired with the continuous, iterative delivery models — Kanban's flow orientation and CI/CD's automated pipeline both assume the kind of frequent, low-drama release DevOps culture is built to sustain — but the cultural argument (shared ownership, blameless review, measure rather than assume) applies regardless of which planning framework sits on top of it.

References