Laws of Software Engineering

Principles

Design rules with strong evidence and well-understood failure modes. Reliable in most situations.

How to use them. Use them as the default position. If you choose to depart from a principle, write down why. The discipline lies in the justification.

How they get misused. Applied without judgement. SOLID applied to every class produces unreadable code. The Testing Pyramid applied without thought produces brittle test suites. A principle followed mechanically becomes a ritual.

• Principle SOLID Five rules for designing object-oriented code: each class does one thing, code should be open to extension but closed to modification, subclasses should be substitutable, interfaces should be small, and code should depend on abstractions rather than specifics.
• Principle Testing Pyramid Have lots of small fast tests, fewer medium tests, very few big slow tests.
• 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 Law of Leaky Abstractions Anything that hides complexity will eventually let some of that complexity show through.
• Principle Tesler's Law (Conservation of Complexity) Every system has some complexity that cannot be removed. You can move it around, but it has to live somewhere.
• Principle Fallacies of Distributed Computing Eight things people wrongly assume about networked systems: the network is reliable, there is no delay, bandwidth is unlimited, the network is secure, the topology never changes, there is one administrator, moving data is free, the network is uniform.
• Principle Lehman's Laws of Software Evolution Software that is being used must keep changing or it goes stale. Without effort, it gets more complicated over time.
• Principle Idempotency An operation should produce the same result whether you run it once or run it ten times.
• Principle Beck's Four Rules of Simple Design A simple design passes its tests, makes intent clear, has no duplicated knowledge, and uses the fewest elements possible. The rules apply in that order.
• Principle Cognitive Load The mental effort needed to understand or change a system. There is a fixed budget per person and per team.
• Principle Observability You cannot run, fix, or improve what you cannot see. Build systems that explain themselves.
• Principle Blameless Retrospectives When something goes wrong, look at the system that allowed it, not the person who triggered it.
• Principle Least Privilege Give every part of the system the smallest set of permissions it needs to do its job, and no more.
• Principle Defence in Depth Build several independent layers of protection. Assume any single layer will fail.
• P Principle Psychological Safety The shared belief that you can speak up, ask questions, admit mistakes, and disagree without being punished or humiliated.
• F Principle Feedback Loops Every system improves at the rate of its slowest feedback loop. Shorten the loops between action and outcome.
• L Principle Leading and Lagging Indicators Leading indicators predict future outcomes. Lagging indicators measure past outcomes. Use both, for different purposes.
• N Principle No Silver Bullet There is no single technique that will produce a ten-fold improvement in productivity within a decade. The hard part is the essential complexity of the problem itself.
• C Principle Conceptual Integrity A system designed by one mind, or by a few minds in close agreement, will be easier to use and understand than one designed by committee.
• C Principle Continuous Delivery Keep software in a state where it could be released to users at any moment, by anyone, with confidence.
• 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.
• B Principle Bounded Rationality People make decisions with incomplete information, limited time, and limited reasoning capacity. They satisfice rather than optimise.
• S Principle Sociotechnical Systems Work systems have a technical subsystem and a social subsystem. Both must be designed together. Optimising one without the other produces worse outcomes than balancing both.
• 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.
• H Principle Hackman's Five Conditions for Effective Teams Teams perform when they are real teams, with compelling direction, enabling structures, supportive context, and expert coaching.
• T Principle The Twelve-Factor App Twelve practices for building software-as-a-service applications that are portable, scalable, and operable. Codebase, dependencies, config, backing services, build/release/run, processes, port binding, concurrency, disposability, dev/prod parity, logs, and admin processes.
• Principle Principle of Least Astonishment Software should behave the way someone familiar with it would expect.
• Principle Law of Demeter A piece of code should only talk to its immediate neighbours. It should not reach through them to talk to strangers.
• H Principle Hick's Law The time it takes to make a decision grows with the number of options.
• Principle Fail-Safe Defaults When something goes wrong or is unspecified, the system should refuse access.