Two Different Jobs: Building vs Running

Making software is really two jobs, not one. There is the work of building it — writing the code, adding features, fixing what's wrong. And there is the separate work of running it — putting it on a server, keeping it online, and making sure real people can use it at three in the afternoon and three in the morning. The same app, two very different kinds of work.

Meet the two people we'll follow for the whole course. Maya is a developer: she writes the code for Pageturn, our small app where people log the books they've read. Sam handles operations: he runs Pageturn on its servers and keeps it healthy for readers. Their goals sound like they should match perfectly. In practice, they quietly pull in opposite directions — and understanding why is the first step to understanding what DevOps is for.

Building: The Drive to Change

Development is the work of making the software do more, or do it better. Maya spends her days adding a "favorites" button, fixing a bug a reader reported, redesigning the sign-up page. Her job is measured in change: a good week is one where Pageturn does something today that it couldn't do last week.

That means a developer is, in a very real sense, rewarded for change. The more useful features ship, the better the app, the better Maya is doing her job. Standing still is the one outcome that counts as failure.

Running: The Drive to Stability

Operations is the work of keeping the software up and healthy once it exists. Sam makes sure Pageturn is online, fast, and not losing anyone's data — that when a reader opens the site, it simply works. His job is measured in the opposite currency from Maya's: not change, but steadiness.

And here is the catch that sets up the entire field of DevOps. The single biggest threat to a stable, running system is a change to it. Most outages don't come from nowhere; they come from someone shipping something new. So Sam, doing his job well, learns to be wary of exactly the thing Maya is paid to produce.

Why the Two Pull Apart

Now you can feel the tension. Maya wants to ship often, because shipping is her value. Sam wants to ship rarely and carefully, because every release is a chance for the site to break on his watch. Neither is wrong. They are two sensible people optimizing for two different things they were each told to care about.

This isn't about personalities or one of them being difficult. It's built into the structure of the two jobs. Point the same tension at any team and it appears: the builders push for speed, the runners push for safety, and left alone, they end up frustrated with each other.

Same Goal, Different Pressures

Step back, though, and Maya and Sam want the very same thing: for Pageturn to serve its readers well. A feature nobody can reach because the site is down is worthless — and so is a rock-solid site that never improves and slowly loses its readers to something better. Good software needs both change and stability, which means it needs both jobs done well.

That shared goal is the ground DevOps is built on. The rest of this course is, in a sense, the long answer to one question: how do you let a team move fast and keep things stable at the same time, instead of forcing a choice between Maya's world and Sam's?