Laws of Programming

2025-01-04   essay programming

Programming laws are distilled wisdom from hard-earned lessons from the trenches. They provide a powerful shorthand for hackers to avoid the same mistakes that have been made time and time again. I’ve grouped them by topic below, and prioritized by how much they’ve saved me from wasted effort.

Avoid early optimization

• Knuth's Optimization Principle: Premature optimization is the root of all evil.
  

• Kent Beck––“Make it run, then make it right, then make it fast.”
  

  • Kent Beck
    

• YAGNI (You Aren’t Gonna Need It): Don’t implement functionality until it’s necessary.
  

Iterate fast, launch early

• Boyd’s Law of iteration: speed of iteration beats quality of iteration.
  

  • John Boyd
    

• LeBlanc’s Law: later equals never
  

• Third Rule of Unix Philosophy: Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
  

• Gall’s Law: A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.
  

  • John Gall
    

Done is better than perfect

• Done is better than perfect: for morale, and also for avoiding early optimization.
  

• Worse is Better: Simplicity of implementation is more important than correctness or completeness.
  

Keep it stupidly simple

• Kernighan's Law: “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
  

• Hoare’s Law of Large Programs: inside every large program is a small program struggling to get out.
  

  • Tony Hoare
    

• KISS (Keep It Simple, Stupid): Simple solutions are better; avoid unnecessary complexity.
  

• Einstein––“Everything should be made as simple as possible, but not simpler”
  

• Antoine de Saint-Exupéry––“Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.“
  

Have an eyesight on complexity

• Lehman’s Law of increasing complexity: Complexity grows unless work is done to reduce it.
  

• Second-System Effect: tendency of small, elegant, and successful systems to be succeeded by over-engineered, bloated systems, due to inflated expectations and overconfidence
  

• Zawinski’s Law: Every program attempts to expand until it can read mail.
  

• Scope Creep: The gradual expansion of a project’s goals and tasks beyond its original objectives
  

• Brian W. Kernighan–“Controlling complexity is the essence of computer programming”
  

Expect it to take longer than expected

• The 90-90 Rule: The first 90% of code accounts for 90% of the development time; the last 10% takes another 90% of the time.
  

• Hofstadter’s Law: It always takes longer than you expect, even when you account for Hofstadter’s Law.
  

Design well

Think your code as lego pieces––Composability

• First Rule of Unix Philosophy: Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
  

• Single Responsibility Principle: A class or module should have one, and only one, reason to exist.
  

• Postel’s law (robustness principle) : "Be liberal in what you accept, and conservative in what you send."
  

• Separation of Concerns: Different aspects of a program should be managed by separate modules or functions.
  

• Separate Understandability Principle: Each module shall be understandable on its own—without knowing anything about other modules.
  

• Loose Coupling: Each component can function independently and make changes without significantly affecting the others
  

• Law of Demeter (Principle of Least Knowledge): a specific case of loose coupling.
  

• Composability enables compounding: “Composability is to software as compounding interest is to finance” –cdixon
  

Be intuitive

• Don't Make Me Think: Designs should be self-evident and intuitive.
  

• Principle of Least Astonishment: Systems should behave in a way that least surprises the user.
  

• Self-documenting code: name your variables and functions for ease of understanding of people reading your code in the future (including yourself)
  

Data model > algorithms

• Linus Torvalds: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships."
  

• Rob Pikes: "Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming."
  

• Eric Raymond (in The Cathedral and the Bazaar)––“Smart data structures and dumb code work a lot better than the other way around.“
  

Debugging

• Fail Fast Principle: Crash early when something goes wrong. It's better to face problems head-on than let them fester.
  

• Linus’s Law: Given enough eyeballs, all bugs are shallow
  

• Murphy’s Law: Anything that can go wrong will go wrong. Write your code to expect failure, not sunshine and rainbows.
  

Profiling: Look for the bottlenecks

• Amdahl’s Law: the overall performance improvement gained by optimizing a single part of a system is limited by the fraction of time that the improved part is actually used
  

• Liebig’s Law of the Minimum: growth is dictated not by total resources available, but by the scarcest resource
  

Trust the old

• Lindy Effect: Code that's been around for a while is likely stable. Don't mess with it unless you have a good reason.
  

• Chesterton’s Fence: Before you remove or refactor code, make sure you understand why it was there in the first place. Deleting unknowns invites new bugs.
  

[This article is mirrored at mirror.xyz]