Laws of Software Engineering

The Interface Contracts cluster

What you promise, what you accept, what your users come to depend on.

Why these together

Postel and Hyrum together describe the contract problem. Be liberal in what you accept, and your users will find every quirk and depend on it. Idempotency makes the contract survive retries. Bounded Contexts and Ubiquitous Language take the same problem upstream, into how the model itself names and shapes its promises.

• Principle Postel's Law Be strict about what you send. Be flexible about what you accept. *This advice is now contested.*
• Principle Hyrum's Law If your software has enough users, every behaviour they can observe will become something they depend on, even if you never promised it.
• Principle Idempotency An operation should produce the same result whether you run it once or run it ten times.
• B Principle Bounded Contexts Different parts of a system can use the same word to mean different things. Draw an explicit boundary around each meaning and translate at the seam.
• U Principle Ubiquitous Language The people who build the software and the people who use it must use the same words to mean the same things. The vocabulary is the design.