hacker-laws

hacker-laws 🧠 Laws, Theories, Principles and Patterns for developers and technologists. 📖 My new book Effective Shell (Online Version) on Amazon (Print/Kindle) 🌍 Try hackerlaws.dev 🧠 Check out my new project Terminal AI 🎧 Listen to the podcast The Changelog - Laws for Hackers to Live By 🌏 See the Translations: 🇧🇷 🇨🇳 🇫🇷 🇮🇹 🇱🇻 🇰🇷 🇷🇺 🇪🇸 🇹🇷 🇮🇩 🇯🇵 🇵🇱 🇻🇳 Introduction Laws 90–9–1 Principle (1% Rule) 90–90 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) Jevons' Paradox Input-Process-Output (IPO) Kernighan's Law Koomey'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 Bitter Lesson The Ringelmann Effect 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 Twyman's law Wadler's Law Wheaton's Law Principles All Models Are Wrong (George Box's Law) Chesterton's Fence Kerckhoffs's principle The Dead Sea Effect The Dilbert Principle The Pareto Principle (The 80/20 Rule) The Shirky Principle The Stochastic Parrot 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 Podcast Contributors 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! This project may in time be turned into a book. Contributions will be acknowledged where reasonably practical. See the Contributing Guidelines for details. Warning: 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 Laws can be opinions on inevitabilities in the world of software engineering, or wry observations on unavoidable realities. 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 90–90 Rule 90-90 Rule on Wikipedia The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time. A wry reinterpretation of the Pareto Principle (or 80-20 rule) that highlights the real-world challenges of completing engineering work. This sentiment is also echoed in Hofstadter's Law. See also: Hofstadter's Law The 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: 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 Brooks' Law Brooks' Law on Wikipedia Adding human resources to a late software development project makes it later. This law suggests that in many cases, attempting to accelerate the delivery of a proj