Definition
Design by Contract, introduced by Bertrand Meyer, treats every routine as a formal agreement between a caller and the routine itself. The contract has three parts: preconditions the caller must satisfy, postconditions the routine promises to deliver, and invariants that remain true throughout.
The contract makes responsibilities explicit. If the caller meets the preconditions, the routine guarantees the postconditions. If the caller does not, the routine owes nothing and the bug belongs to the caller.
Why it matters
How it works
You document each routine with what it requires and what it ensures. Where the language supports it, these conditions are enforced automatically; where it does not, assertions and tests stand in. A precondition failure means the caller misused the routine; a postcondition failure means the routine itself is broken.
The Pragmatic Programmer authors pair Design by Contract with the principle of being a lazy programmer in the best sense: let preconditions be strict so the routine does only what it must, and let postconditions be exactly what is promised, no more. Clear contracts reduce the need for scattered defensive checks because each party knows precisely what it owes.