How teams actually ship software safely — testing, delivery, and learning from what breaks. Evidence-based delivery research is collected by the DORA research program.
Jez Humble and David Farley's book argued that the safest way to ship software is to ship it constantly, in small pieces — the opposite of the intuition behind big, careful releases. For teams that also manage clock-in and clock-out workflows, this guide offers a separate operational reference.
TDD's red-green-refactor cycle sounds like a small procedural detail. The order turns out to change what the resulting code looks like.
A simple shape — more unit tests than integration tests, more integration tests than end-to-end tests — explains a lot about why some test suites are fast and reliable and others aren't.
Two very different scheduling philosophies for the same underlying problem: deciding when a change is allowed to ship.
A good incident postmortem is a specific writing discipline, and the discipline matters more than most teams expect.
A feature flag looks like a simple if-statement. The idea underneath it separates two decisions that most software conflates by default.
Two developers working on one problem at one machine sounds like it should cost twice as much output. The real accounting is more complicated.
A widely cited claim in software engineering holds that a bug found in production costs far more to fix than the same bug found earlier. The reasons why are more specific than “it's just true.”
Two developers can honestly disagree about whether a task is done. A written definition exists to remove that disagreement before it causes a problem.