A cumulative snapshot of every article published up to Why Long-Running Branches Are a Tax on Everyone Else on June 15, 2026. 4 articles. View the current list →
The demo worked, the team hit the date, and everyone felt good for about thirty minutes. Then the support tickets started. Boring software is not dull to build, it is uneventful to operate. The thing you ship can be clever and satisfying, but running it in production should be routine: practiced rollbacks, clear ownership, and no reliance on heroics. That kind of boring is engineered, not accidental.
I started writing software before source control was a given: you found out who changed a file by asking around. Git made creating branches cheap, but it never made integrating them cheap. Long-running branches feel productive for the developer who opens them, but the cost lands on everyone else through delayed integration, hidden assumptions, and uncertainty that surfaces right before a release. Trunk-based development is less a trend than the natural consequence of taking CI/CD seriously.
Somewhere in most codebases there is a clever abstraction that saved three days of development and has been collecting interest ever since. Cost-adjusted software engineering judges work by the value it creates against the full cost of building and operating it, not just whether it shipped. You can pay up front through testing, CI/CD, and clear ownership, or pay forever through incidents and rework.
Every software system exists twice: once as what the team believes it built, and once as what shows up after it ships. This blog lives in the gap between the two. Notes on ownership, deployment, operations, and the human layer underneath. Most architecture problems are really ownership problems.
