Laws of Software Engineering

Sayings

Sharp phrases that make you think. They cannot decide a design question.

How to use them. Use them as prompts. YAGNI before adding a feature. Chesterton's Fence before removing one. Hanlon's Razor before blaming someone. The saying works by interrupting your first instinct.

How they get misused. Treated as conclusions. A saying that ends an argument is doing the opposite of its job. If "YAGNI" is your last word on a feature, you used the saying to skip the thinking.

• Saying YAGNI (You Aren't Gonna Need It) Do not build features you might need someday.
• Saying KISS (Keep It Simple, Stupid) The simpler version usually wins.
• Saying DRY (Don't Repeat Yourself) Each piece of knowledge in the system should live in one place.
• Saying Broken Windows Visible mess invites more mess.
• Saying Linus's Law Given enough people looking at the code, every bug becomes obvious to someone.
• Saying Kernighan's Law Debugging is twice as hard as writing the code. So if you write it as cleverly as you can, you cannot debug it.
• Saying Hanlon's Razor Do not assume someone is being malicious if carelessness explains it.
• Saying Murphy's Law Anything that can go wrong will go wrong.
• Saying Occam's Razor The simplest explanation is usually the right one.
• Saying Sunk Cost Fallacy What you have already spent is not a reason to keep going.
• Saying Confirmation Bias You see what you expect to see.
• Saying Inversion Solve a problem by asking how it could fail. Work backwards from there.
• G Saying Gilb's Law Anything you need to measure can be measured in some way that is better than not measuring it at all.
• Saying Chesterton's Fence Do not remove a fence until you understand why it was put there.
• Saying Reversibility (Two-Way Doors) Some decisions are easy to undo. Some are not. Spend more time on the ones that are not.
• T Saying The New View (Dekker) Human error is not a cause of failure. It is a symptom of trouble deeper in the system.
• O Saying Outcome over Output Build to change something in the world, not to ship a feature.
• V Saying Vanity vs Actionable Metrics A vanity metric makes you feel good. An actionable metric changes a decision.
• T Saying The McNamara Fallacy What can be measured easily gets attention. What cannot gets ignored. Eventually the unmeasured is declared unimportant.
• T Saying The Five Ideals Five conditions for an effective software organisation. Locality and simplicity. Focus, flow, and joy. Improvement of daily work. Psychological safety. Customer focus.
• J Saying Just Culture A culture that holds people accountable for the work they did, while looking honestly at the system that shaped the choices they had.
• T Saying The Iceberg of Ignorance Most of the problems frontline workers know about never reach leadership. The proportion grows the further up you go.
• T Saying The Future Is Already Here (Gibson) The future is already here. It is just not evenly distributed.
• Saying The Happy Camper Rule Leave the code better than you found it.
• Saying Pesticide Paradox Running the same tests over and over catches the same bugs. Different bugs go unnoticed.
• Saying The Map Is Not the Territory Your model of the system is not the system.
• Saying Dunning-Kruger Effect People with the least knowledge of a subject tend to be the most confident about it.
• Saying First Principles Thinking Break a problem down to its most basic parts. Build back up from there.
• I Saying INVEST A good user story is Independent, Negotiable, Valuable, Estimable, Small, and Testable.
• F Saying Five Dysfunctions of a Team Teams fail in five layered ways: absence of trust, fear of conflict, lack of commitment, avoidance of accountability, and inattention to results.
• T Saying The Five Whys Ask "why" five times to get past symptoms and find the underlying cause.