Ship Small Diffs

• Git allows lots of branches, and lots of merge and conflict resolution options. Avoid them.
  • “You should start from practices that work operationally, and follow the path backwards to what is done in development. Even allowing for discardable MVP’s, ultimately in a working business most of the cost of software is in operating it, not building it.”
• Ship small diffs, and stand a snowball’s chance of inspecting them for correctness.
• Ship small diffs, because code isn’t correct until it’s running production.
  • “The senior developer’s conditioned emotional response to a large deploy diff is abject terror. This is an instinctive understanding of a simple relationship.”
  • “Every line of code has some probability of having an undetected flaw that will be seen in production. Process can affect that probability, but it cannot make it zero. Large diffs contain many lines, and therefore have a high probability of breaking when given real data and real traffic.”
• Ship small diffs, because the last thing you changed is probably setting those fires.
  • Because most production issues are caused by recent changes, usually bad code, “[debugging a production issue] is a code review performed under duress. So the time to recover from problems in production will tend to be proportional to the size of the diffs that you’re releasing.”
• Taking Small Diffs Seriously
  • Branches have inertia, and it is bad: I tell people that it’s fine with me if working in a branch helps them, as long as I’m not ever able to tell for sure that they’re doing it."