How to Guarantee You Never Ship

This blog post series explores lessons learned while growing and selling SaaS product companies. In a run of posts, the author has previously argued against splitting code across many repositories, using long-lived feature branches, implementing microservices, dedicated quality assurance, setting a fixed test coverage target, and using pull-request reviews as quality gates.

This post focuses on the inverse of those best practices, aiming to create an organization that never delivers anything, even though each decision appears responsible in meetings.

The article begins by splitting the system across many repositories, one per service or team, for clean ownership. It then allows work to happen on long-lived feature branches, so serious features can be built. The system is cut into as many microservices as possible, preferably small ones, so every interaction crosses the network. Each change requires a reviewed pull request before any merge, and every change must meet 90% test coverage before merging. A dedicated QA stage is also put in place to catch any issues.

The author emphasizes that each of these choices is defensible in isolation, but together they form a delivery-proof machine. The issue arises when one step adds a coordination boundary, and coordination boundaries do not simply add up - they multiply. Modifying a shared concept that several parts of the system use requires four pull requests, each reviewed by someone with only their slice in view.

The change must clear the coverage gate on its own, and it has to survive a merge against weeks of drift, as each repository is on long-lived branches.

The process of adding a field to a shared concept becomes even more complicated when it crosses multiple branches and services, requiring multiple pull requests, each reviewed independently. The field must be added on both sides of every boundary, and the system is deployed separately, so production runs a mix of versions for a while.

This leads to QA being handed an incomplete and chaotic result, with testing focused on the wrong combination of versions. The complexity increases exponentially with the number of repositories, branches, services, and review queues. The author argues that the cost of shipping a single coherent change becomes prohibitively high.

The article concludes that the problem lies not in the individuals making these decisions, but in the system itself. The author draws a comparison to a sabotage manual written by the US Office of Strategic Services during World War II, where the focus was on creating a system so complex that it becomes impossible to coordinate and ship changes.

The author emphasizes that the issue is not about the intent behind each step, but rather the lack of ownership and visibility for the final product. The system that was designed for clarity has become a delivery-proof machine that cannot be comprehended or shipped effectively.