Ship Small Diffs (2017)

Many teams start projects by reaching for the advanced branching and tagging capabilities that Git provides, treating them as default workflow tools. This habit often results in long-lived branches and large change sets that are merged infrequently. The article observes that this approach puts the cart before the horse, prioritizing developer convenience over operational safety. It proposes instead to begin with what works in production and let development practices follow from there.

Operational reality shows that most of a software system’s lifetime cost is incurred after code is deployed, not during its initial creation. By measuring success in terms of running code rather than committed code, the focus shifts to delivering value that can be observed in production. Deploying small units of code regularly aligns the development rhythm with the operational feedback loop. This makes the cost of fixing mistakes lower because errors are caught closer to their source.

Reviewing a diff that contains only a dozen lines is a manageable task that stays within human attention limits, reducing the temptation to give a perfunctory “looks good” approval. When a problem surfaces in production, the recent small change set provides a clear clue about what might have caused it, shortening the investigation. The article notes that debugging time tends to grow with the size of the released diff, so keeping diffs small directly cuts mean-time-to-repair. Consequently, the overall reliability of the service improves without requiring heavierweight processes.

The practice assumes that changes can be meaningfully isolated; when features require coordinated modifications across many files, splitting them into tiny diffs may add overhead or create temporary inconsistencies. Teams must invest in discipline and lightweight tooling, such as simple git diff pipelines, to keep change sets small without sacrificing traceability. If the organization’s culture rewards large, infrequent releases or lacks automated testing, the benefits of small diffs erode. In those contexts the approach may stop working because the underlying incentives and tooling do not support frequent, verifiable pushes.