💻📖 hacker-laws

Laws, Theories, Principles and Patterns that developers will find useful.

Translations: 🇮🇩 🇧🇷 🇨🇳 🇩🇪 🇫🇷 🇬🇷 🇮🇹 🇱🇻 🇰🇷 🇵🇱 🇷🇺 🇪🇸 🇹🇷 🇯🇵 🇺🇦 🇻🇳

Like this project? Please considering sponsoring me and the translators. Also check out this podcast on The Changelog - Laws for Hackers to Live By to learn more about the project! You can also download the latest PDF eBook. Check the Contributor Guide if you are keen to contribute!

---

• Introduction
• Laws
  • 90–9–1 Principle (1% Rule)
  • Amdahl's Law
  • The Broken Windows Theory
  • Brooks' Law
  • CAP Theorem (Brewer's Theorem)
  • Clarke's three laws
  • Conway's Law
  • Cunningham's Law
  • Dunbar's Number
  • The Dunning-Kruger Effect
  • Fitts' Law
  • Gall's Law
  • Goodhart's Law
  • Hanlon's Razor
  • Hick's Law (Hick-Hyman Law)
  • Hofstadter's Law
  • Hutber's Law
  • The Hype Cycle & Amara's Law
  • Hyrum's Law (The Law of Implicit Interfaces)
  • Kernighan's Law
  • Linus's Law
  • Metcalfe's Law
  • Moore's Law
  • Murphy's Law / Sod's Law
  • Occam's Razor
  • Parkinson's Law
  • Premature Optimization Effect
  • Putt's Law
  • Reed's Law
  • The Law of Conservation of Complexity (Tesler's Law)
  • The Law of Demeter
  • The Law of Leaky Abstractions
  • The Law of the Instrument
  • The Law of Triviality
  • The Unix Philosophy
  • The Scout Rule
  • The Spotify Model
  • The Two Pizza Rule
  • Wadler's Law
  • Wheaton's Law
• Principles
  • All Models Are Wrong (George Box's Law)
  • Chesterton's Fence
  • The Dead Sea Effect
  • The Dilbert Principle
  • The Pareto Principle (The 80/20 Rule)
  • The Shirky Principle
  • The Peter Principle
  • The Robustness Principle (Postel's Law)
  • SOLID
  • The Single Responsibility Principle
  • The Open/Closed Principle
  • The Liskov Substitution Principle
  • The Interface Segregation Principle
  • The Dependency Inversion Principle
  • The DRY Principle
  • The KISS principle
  • YAGNI
  • The Fallacies of Distributed Computing
  • The Principle of Least Astonishment
• Reading List
• Online Resources
• PDF eBook
• Podcast
• Translations
• Related Projects
• Contributing
• TODO

Introduction

There are lots of laws which people discuss when talking about development. This repository is a reference and overview of some of the most common ones. Please share and submit PRs!

New paragraph!!!!!

❗: This repo contains an explanation of some laws, principles and patterns, but does not advocate for any of them. Whether they should be applied will always be a matter of debate, and greatly dependent on what you are working on.

Laws

And here we go!

Hello, I'm teh new paragraph!!!

90–9–1 Principle (1% Rule)

1% Rule on Wikipedia

The 90-9-1 principle suggests that within an internet community such as a wiki, 90% of participants only consume content, 9% edit or modify content and 1% of participants add content.

Real-world examples:

• A 2014 study of four digital health social networks found the top 1% created 73% of posts, the next 9% accounted for an average of ~25% and the remaining 90% accounted for an average of 2% (Reference)

See Also:

• Pareto principle

Amdahl's Law

Amdahl's Law on Wikipedia

Amdahl's Law is a formula which shows the potential speedup of a computational task which can be achieved by increasing the resources of a system. Normally used in parallel computing, it can predict the actual benefit of increasing the number of processors, which is limited by the parallelisability of the program.

Best illustrated with an example. If a program is made up of two parts, part A, which must be executed by a single processor, and part B, which can be parallelised, then we see that adding multiple processors to the system executing the program can only have a limited benefit. It can potentially greatly improve the speed of part B - but the speed of part A will remain unchanged.

The diagram below shows some examples of potential improvements in speed:

(Image Reference: By Daniels219 at English Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)

As can be seen, even a program which is 50% parallelisable will benefit very little beyond 10 processing units, whereas a program which is 95% parallelisable can still achieve significant speed improvements with over a thousand processing units.

As Moore's Law slows, and the acceleration of individual processor speed slows, parallelisation is key to improving performance. Graphics programming is an excellent example - with modern Shader based computing, individual pixels or fragments can be rendered in parallel - this is why modern graphics cards often have many thousands of processing cores (GPUs or Shader Units).

See also:

• Brooks' Law
• Moore's Law

The Broken Windows Theory

The Broken Windows Theory on Wikipedia

The Broken Windows Theory suggests that visible signs of crime (or lack of care of an environment) lead to further and more serious crimes (or further deterioration of the environment).

This theory has been applied to software development, suggesting that poor quality code (or Technical Debt) can lead to a perception that efforts to improve quality may be ignored or undervalued, thus leading to further poor quality code. This effect cascades leading to a great decrease in quality over time.

See also:

• Technical Debt

Examples:

• The Pragmatic Programming: Software Entropy
• Coding Horror: The Broken Window Theory
• OpenSource: Joy of Programming - The Broken Window Theory