On the Inversion of Practices
How Software Industry Inverts Every Good Idea
Next week I’m heading to New York for Tech Week. I always look forward to the trip — partly for the events, partly because New York is just a great city to land in. If you’ve never been, MoMA is one of those places worth carving out half a day for. Starry Night, the Rothkos, the Picassos, and so on.
MoMA is also home to a funny story.
In October 1961, the museum opened a new exhibition: The Last Works of Matisse: Large Cut Gouaches. Among the pieces was Matisse’s Le Bateau — a sailboat and its reflection. It hung in the gallery for 47 days before a visitor, a stockbroker named Genevieve Habert, pointed out that it was upside down. The reflection was on top. The boat was on the bottom. Tens of thousands of people had walked past it, and no one else noticed.
The software industry runs on a similar trick.
There’s a pattern in tech that’s so reliable you could almost set a watch by it. Someone has a good idea. The idea spreads and turns into practice. Within one cycle, the industry has implemented something that is, on close inspection, pretty much the opposite of what the practice was supposed to be. And yet, we keep the original name.
Agile is the obvious one. The original manifesto is 25 years old. It’s eight bullet points long, and almost militantly anti-process. “Individuals and interactions over processes and tools.” “Responding to change over following a plan.” What we built on top of it is two-week deadline cycles dressed up as sprints, and Jira workflows with more states than the periodic table. The retrospective — the one ritual whose entire job was to change something — became the meeting everyone skips (or has lost hope that it can meaningfully improve anything). We took a document arguing against process and turned it into a process-heavy way to ship software. Hell, we've even built an entire certification industry on top of it — over a million SAFe-certified professionals, another 1.5 million through Scrum Alliance!
DevOps had a simpler fate. The whole point was to tear down the wall between development and operations. Shared ownership. No handoffs. Engineering teams responsible for what they shipped. So we built a new wall, painted “DevOps” on it, and hired a team to stand behind it. The job posting reads: “DevOps Engineer — own the CI pipeline so the developers don’t have to.” The wall is taller now, and it has a Jira queue.
Microservices were supposed to give teams independent deployability. Small services, clear contracts, deploy on your own schedule. What most companies actually built is a distributed monolith — every service depending on every other service, except now the dependencies travel over a network with retries and timeouts and a 40-page runbook. We didn’t decouple the system. We decoupled the deployments and coupled everything else harder. The reward for splitting your monolith is that now your monolith has latency.
And — the part that got me thinking about all this from my previous article — the Product Trio. Cagan’s point was that PM, design, and engineering should sit so close together that the seams disappear. One team, three skills, one outcome. What we built instead is three sub-organizations with separate VPs, separate roadmaps, and a shared Confluence space. The trio became a triad became a tax.
So why does this keep happening? My working theory is dull.
Good ideas in our industry arrive as practices, and orgs metabolize practices the only way they know how — by assigning them a manager, a budget line, and a team name. The practice dies on contact with the org chart. The main aspect that survives is the name.
With the AI revolution, we are about to have new ideas. Ideas that will improve how we build software at scale. The next big idea may be about how product disciplines collapse into each other, with AI as the connective tissue.
And yet — give it a cycle. I suspect it will have a separate vertical in the org chart and a VP before the cycle ends.