Rule 33 of 38 · Chapter VI — Shipping Is Part of Engineering
Shipping is a feature
Why this rule exists
Software that never ships delivers no value, gathers no feedback, and teaches you nothing about whether you built the right thing. Work sitting on a branch is inventory: it decays, it collides with everyone else's changes, and its risk grows the longer it waits. Treating the act of shipping as a first-class part of the work, not an afterthought, is what turns effort into outcomes.
In practice
Plan the release path when you plan the feature, not after it's coded. Keep changes small enough to ship in days, and keep the main branch always deployable. Invest in the boring machinery that makes shipping routine: tests, a fast pipeline, one-command deploys. Measure lead time from commit to production and treat a slow or scary release process as a bug to fix.
When it doesn't apply
Some things genuinely shouldn't ship the moment they compile: safety-critical systems, regulated changes, and coordinated launches need gates. Slow down deliberately where the cost of a mistake is high, but keep the slowness intentional rather than accidental.