Three Rules of Test-Driven-Development

The Three Rules of TDD are simple: Write no production code until you have a failing test. Write only enough tests to fail. Write only enough production code to pass. When builders follow this discipline, their work is verifiable every minute. Small, frequent checks catch errors early and keep risk manageable. TDD is the balance sheet that helps us avoid catastrophes. Discussions for your team Which high-risk parts of our software would benefit from requiring strict TDD? In which areas of our software are we resisting writing tests first, and why? What tooling would make TDD easier?

2025 June 11

Double-Entry Bookkeeping

You may have heard the comparisons of software building with accounting. Accountants create dense, technical records, and utilize the method of double-entry to keep their bookkeeping in order. Every transaction is entered twice so the balance sheet always sums to zero. Accountants check balances frequently, catching mistakes early. A discipline enforced by law in many regions around the world. Test-Driven Development (TDD) is the developers’ double-entry bookkeeping. Writing an executable automated test first and then running it frequently lets developers detect and identify errors immediately, keeping the feedback loop tight, and preventing cascading failures. ...

2025 June 10