Since I was in school, I like to read the laws and theories summarized by previous research. There are also several such articles in blog posts. Today I saw a pretty good summary on Github, and it is based on the MIT license, so I reprinted it.
Source address: https://github.com/dwmkerr/hacker-laws
Introduction
When people talk about development, they talk about many laws. This repository contains some of the most common laws.
[scode type=“yellow”]This repository contains explanations of a number of laws, principles, and patterns, but does not advocate any of them. Their application is always subject to debate and depends largely on what you are doing. [/scode]
Law
Let’s get started now!
90-9-1 Principle or 1% Rule
- [English Wikipedia](https://en.wikipedia.org/wiki/1%25_rule_(Internet_culture)
- Chinese Wikipedia
The 90-9-1 rule states that in an Internet community such as a wiki, 90% of users only read content and do not interact, 9% of users participate in discussions, and only 1% of users create content.
Real world example:
- A 2014 study of four healthy digital social networks found that the top 1% created 73% of posts, the next 9% averaged 25%, and the remaining 90% averaged 2%. (Reference)
See also:
- [The Pareto Principle or The 80/20 Rule](#Pareto Principle-the-pareto-principle-or-the-8020-rule)
Amdahl’s Law
Amdahl’s law is a formula that shows the potential acceleration of a computing task. This capability can be achieved by increasing system resources, often used in parallel computing. It predicts the practical benefits of increasing the number of processors, however increasing the number of processors will be limited by program parallelism.
To illustrate: If a program consists of two parts, part A must be executed by a single processor and part B can run in parallel. Adding multiple processors to a system that executes programs would then yield only limited benefits. It can greatly increase the speed of part B, but the speed of part A will remain the same.
The following figure shows some examples of potential speed improvements:
(Image source: By Daniels220 at English Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)
It can be seen that a 50% parallelized program achieves little speedup after using more than 10 processing units, while a 95% parallelized program can still achieve significant speedup after using more than a thousand processing units.
As the speed of individual processors increases slowly, parallelization is key to improving performance as Moore’s Law slows down. Graphics programming is an excellent example, where modern shaders can render individual pixels or fragments in parallel. This is why modern graphics cards typically have thousands of processing cores (GPUs or shader units).
See also:
The Broken Windows Theory
In the broken windows theory, it is believed that some obvious signs of crime (or lack of environmental awareness) can lead to further and more serious crimes (or further degradation of the environment).
The Broken Window Theory has been applied to software development and suggests that poor code (or Technical Debt) may further degrade the code by affecting the efficiency of subsequent optimizations; over time, this effect will lead to a significant decline in code quality.
See also:
Example:
- “The Pragmatic Programming: Software Entropy”
- “Coding Horror: The Broken Window Theory”
- “Open Source: Joy of Programming - The Broken Window Theory”
Brooks’s Law
In the later stages of software development, adding manpower will only make the project develop slower.
This law states that in many cases, trying to speed up the delivery of a delayed project by adding manpower will cause the project to be delivered even later. Brooks also understands that this is an oversimplification. But the general argument is that the added time and communication overhead of new resources will slow down development in the short term. Moreover, many tasks are inseparable, in other words, this allows more resources to be easily distributed among them, which also means that the potential speed increase is also lower.
The proverb Nine women cannot have a baby in a month is the same as Brooks’ Law, especially for certain indivisible or parallel tasks.
This is the central theme of The Myth of the Man-Moon.
See also:
CAP Theorem (CAP Theorem or Brewer’s Theorem)
The CAP theorem was defined by Eric Brewer, which states that for distributed data storage, it is impossible to satisfy the following three points at the same time:
- Consistency: When reading data, each request will receive the latest data or return an error.
- Availability: When reading data, each request will receive a non-error response, but there is no guarantee that the data is the latest data.
- Partition Tolerance: When any number of network requests between nodes fail, the system can continue to operate as expected.
The core argument is as follows: Because there is no guarantee that there will be no network partitions (see The Fallacies of Distributed Computing), in the case of partitions, we can choose to cancel the current operation (increase consistency and decrease availability), or choose to continue the operation (increase availability and decrease consistency).
The name of the theorem comes from the first letters of Consistency, Availability, and Partition Tolerance. Note that this has nothing to do with ACID, which has another definition of consistency. The recently developed PACELC theorem adds constraints to the CAP theorem on latency and consistency when the network is not partitioned (that is, when the system operates as expected).
Most modern database platforms indirectly acknowledge this theorem by providing the database user with the option to choose between a highly available operation (such as a “dirty read”) or a highly consistent operation (such as a “quorum acknowledged write”).
Real world example:
- Inside Google Cloud Spanner and the CAP Theorem - This article details how Cloud Spanner works. On the surface, the platform seems to be able to guarantee CAP three, but in fact it is still a CP system, that is, only consistency and partition fault tolerance.
See also:
Conway’s Law
This law states that the technical boundaries of a system can reflect the structure of an organization and is often addressed when improving an organization. Conway’s Law states that if an organization is fragmented into many small, disconnected units, then the software it develops will also be small and fragmented. If the organization is more of a vertical structure that is functional or service-oriented, then the software system will reflect that.
See also:
Cunningham’s Law
The best way to get the right answer on the Internet is not to ask a question, but to post a wrong answer.
According to Stephen McKeady, Ward Cunningham suggested to him back in the early 1980s that the best way to get the right answer on the Internet was not to ask a question but to post a wrong answer. McGeady called this Cunningham’s law, but Cunningham dismissed it and felt it was a “misquotation.” Initially this law was only used to describe social behavior on Usenet, but it has gradually been applied to other online communities (such as Wikipedia, Reddit, Twitter, Facebook, etc.).
See also:
Dunbar’s Number
Dunbar’s number is the cognitive limit to the number of people a person can maintain stable social relationships—relationships in which a person knows who everyone is and how everyone relates to everyone else. There is some disagreement as to the exact value of this number. Dunbar points out that a person can easily maintain only 150 stable relationships. This relationship is in a more social context where when you happen to meet these people in a bar, you don’t feel embarrassed to join them. Estimates of Dunbar’s number generally range from 100 to 250.
Like stable relationships between people, the relationship between a developer and their code base takes work to maintain. When faced with large, complex projects, or ownership of many projects, we rely on conventions, strategies, and modeling processes to scale. Dunbar’s number is important not only in the process of scaling an office, but also in setting the scope of a team’s work, or deciding when a system should focus on tools that assist in modeling and automating organizational management overhead. To put Dunbar’s number in engineering content as an analogy, it’s the number of projects you can join and be confident you can rotate on-call (or the normalized complexity of a single project).
See also:
The Dunning-Kruger Effect
Incompetent people are often unaware of their own incompetence. And the skills required to come up with the right answer are the same skills you need to recognize what the right answer is.
The Dunning-Kruger effect is a theoretical cognitive bias described by David Dunning and Justin Kruger in a 1999 psychology study and paper. Research shows that people with lower levels of ability at a task are more likely to overestimate their abilities. This bias occurs because a person has enough awareness of the complexity of a problem or field to be able to make an informed opinion about his or her ability to work in that field.
There is another similar, more explicit description of the Dunning-Kruger effect, which is that “the less a person knows about a certain field, the easier it is for him to despise the difficulty of this field, and thus he is more inclined to believe that he can easily solve problems in this field.” This effect is highly technology-related, whereby individuals who are less familiar with a domain (such as non-technical team members or team members with less experience) are more likely to underestimate the amount of effort required to solve problems in that domain.
As understanding and experience in a certain field increases, people are likely to encounter another effect - Illusory superiority, in which extensive experience in a specific field makes them more likely to overestimate the abilities of others, or underestimate their own abilities. Taken together, these effects are attributed to cognitive biases. When we realize that biases exist, we can try our best to put forward opinions to eliminate these biases, so that objections can often be avoided.
Real case:
- Apple vs. FBI: Why This Anti-Terror Hawk Switched Sides - In 2016, Senator Lindsey Graham reversed his stance on Apple creating a “backdoor” in device encryption. Initially, Graham had criticized Apple for opposing the creation of a “backdoor” because he believed it was necessary to investigate potential terrorist plans. However, as he learned more about the technical complexities of the field, Graham realized that it would be much more difficult than he originally thought and could have serious negative consequences. This is a true example of the Dunning-Kruger effect - cybersecurity experts will know better how to exploit such a backdoor because they have a deep understanding of the field; while laypeople may simply analogize device security to physical security, and law enforcement can use “master keys”, but this is obviously not the same as modern encryption in cybersecurity.
Fitts’s Law
This law states that the time required to move to a target area is a function of the distance to the target divided by the width of the target.
(Image source: By Foobar628 at English Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/Fitts%27s_law#/media/File:Fitts_Law.svg)
Fitts’ Law dictates that when designing a UX or UI, interactive elements should be as large as possible, while the distance between the user’s attention area and the interactive elements should be as small as possible. This has implications for design, such as grouping similar tasks into categories.
It also formalized the concept of “Magic Corners,” placing key UI elements in corners so that users can easily click on them by moving their mouse. The Windows start button is located at the magic angle for easy selection, but what is interesting is that MacOS is just the opposite. Its “Close Window” button is not at the magic angle, which can effectively reduce the probability of being accidentally clicked.
See also:
Gall’s Law
A feasible complex system must develop from a feasible simple system. A complex system designed from scratch is simply not feasible and cannot be tinkered with to make it feasible. You have to start over with a simple system that works.
John Gall (John Gall)
Gale’s Law states that designing highly complex systems is likely to fail. They are difficult to achieve overnight and more often evolve from simple systems.
The most typical example is the Internet. Today’s Internet is a highly complex system that was originally defined as a way to share content between academic institutions. The Internet succeeded in its original goals and evolved over time into the complex prosperity it has today.
See also:
Goodhart’s Law
Any observed statistical constancy tends to dissipate when pressure is exerted on it for control.
Charles Goodhart
See also:
When a measure becomes a goal in itself, it ceases to be a good measure.
Marilyn Strathern
According to this law, optimization driven by measurement may lead to a decrease in the convincingness of the measurement results themselves. Blindly using some overly strict screening methods (KPIs) may have some adverse effects. People will tend to use “loophole” behavior to do local optimization to meet some specific metrics without caring about the overall results.
Real-life example:
- Assert-free testing can achieve code coverage expectations, but the goal of measurement should be to create well-tested software.
- Evaluating developer performance by the number of lines of commits leads to unreasonable code base expansion.
See
Hanlon’s Razor
If it can be interpreted as stupid, don’t interpret it as malicious.
Robert J. Hanlon
This principle states that the negative consequences of an action are not malicious. Instead, negative outcomes are more likely to be attributed to these actions or impacts that are not well understood.
Hick’s Law or Hick-Hyman Law
Decision time increases logarithmically with the number of options available.
William Edmund Hick and Ray Hyman
In the equation below, T is the time it takes to make a decision, n is the number of options, and b is a constant determined by data analysis.
(Image reference: Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/Hick%27s_law)
This law only applies when the options are arranged in order, such as ABCD. This is implicit in the base-two logarithm, which means that the decision maker is essentially performing a binary search. Experiments have shown that if the options are not arranged in order, the time spent will increase linearly with the number of options.
In UI design, this law can also be effective in ensuring that users make decisions more easily and pleasantly when searching for options.
As can be seen in the article Speed of Information Processing: Developmental Change and Links to Intelligence, the correlation between IQ and reaction time also satisfies Schick’s law.
See also:
Hofstadter’s Law
Even taking into account Hofstadter’s Law, it always takes longer than you expect.
Douglas Hofstadter
You may hear this law when estimating how long development will take. There seems to be a truism in software development that we often cannot accurately estimate how long it will take to complete.
The words come from “Gödel, Escher, Bach: A collection of different masterpieces”.
See also:
Hutber’s Law
To improve is to worsen.
Patrick Hutber (Patrick Hutber)
This law states that improvements to one system can lead to deterioration in other parts; or it can hide other deteriorations and lead to a degradation of the overall state of the system.
For example, a reduction in response latency on one endpoint can cause throughput and capacity issues to increase further in the request stream and impact an entirely different subsystem.
Hype Cycle (The Hype Cycle or Amara’s Law)
We tend to overestimate the impact of technology in the short term and underestimate the long-term effects.
Roy Amara
The Hype Cycle is Gartner’s visual representation of the initial emergence and development of a technology. A picture is worth a thousand words:
(Image source: By Jeremykemp at English Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)
In short, this cycle shows that new technologies and their potential impacts often create waves. Teams quickly adopt these new technologies and are sometimes disappointed with the results. This may be because the technology is not yet mature enough, or real-world applications have not yet been fully realized. Over time, as the capabilities of the technology improve, the actual opportunities to use it increase, and ultimately the team can become more productive. Roy Amara sums it up succinctly: We tend to overestimate the short-term effects of technology and underestimate the long-term effects.
Hyrum’s Law or The Law of Implicit Interfaces
When the API has enough users, your commitments in the contract no longer matter: all observable behavior of your system will be relied upon by someone.
Hyrum Wright
The law of implicit interfaces states that when your API has enough users, all behavior of the API (including those not covered by the public specification) will eventually be relied upon by others. A simple example is a non-functional factor such as the API’s response time; a more subtle example is when users use regular expressions to match error prompts to determine the error type of the API, even though the API documentation does not contain any content about error prompts, but guides users to use the corresponding error codes. Some users will still use the error message content (rather than the error code). In this case, changing the API error message will actually break the use of the API.
See also:
Kernighan’s Law
Debugging is twice as difficult as writing a program in the first place. So, by definition, if your code is written very cleverly, you are not equipped to debug it.
Brian Kernighan
Kernighan’s Law is named after Brian Kernighan (Brian Kernighan), a quote from the book “The Elements of Programming Style” by Kernighan and P.J. Plauger:
Everyone knows that debugging is twice as difficult as writing a program in the first place. So, if you’re as clever as possible when writing it, how do you debug it?
While this is an exaggeration, it makes the argument that simple code is preferable to complex code because any problems that arise while debugging complex code will be intractable or even impossible to solve.
See also:
Linus’s Law
Enough eyes and all questions can emerge.
Eric S. Raymond
Simply put, the more people who can see the problem, the higher the likelihood that someone has solved the problem or issue in question.
This law was originally used to describe the value of the open source model to a project and is applicable to any software project. It can also be extended into the development process - more code reviews, more static analysis and multiple tests can make problems more obvious and easier to identify.
A more formal statement of Linus’s law is as follows:
If there is a large enough base of testers and co-developers, almost every problem can be quickly characterized so that it can be solved by people who have encountered similar problems before.
This law first appeared in the book “The Cathedral and the Bazaar” by Eric S. Raymond and was named in honor of Linus Torvalds.
Metcalfe’s Law
In network theory, the value of a system is approximately equal to the square of the number of system users.
This law is based on the number of possible connected pairs in a system and is very similar to Reed’s Law. Odlyzko and others argue that Reed’s and Metcalfe’s laws overstate the value of the system itself because they do not take into account the limits of human cognition in network effects.
See also:
Moore’s Law
The number of transistors in integrated circuits doubles approximately every two years.
This law is often used to describe the sheer rate at which semiconductor and chip technology improves. From the 1970s to the 2000s, Moore’s predictions proved highly accurate. In recent years, this trend has changed slightly, partly due to the influence of quantum tunneling. However, advances in parallelized computing, along with potentially revolutionary changes in semiconductor technology and quantum computing, could mean Moore’s Law continues to hold true for decades to come.
Murphy’s Law / Sod’s Law
Everything that can go wrong will go wrong.
From Edward A. Murphy Murphy’s Law states that if something can go wrong, it will.
This is a common saying among developers. During development, testing and even production, some unexpected things may happen. This law can also be referred to Saud’s theorem which is more common in British English:
If something can go wrong, it will happen at the worst possible time.
These laws are often used in humorous mockery. However, phenomena like Confirmation Bias and Selection Bias can easily lead to overemphasis on these laws (i.e., in most cases, success will appear commonplace; failure will attract more attention and discussion).
See also:
Occam’s Razor
Do not add entities unless necessary.
William of Ockham
Occam’s razor states that among several possible solutions, the most likely solution is the one with the fewest concepts and assumptions. Because this solution is the simplest, it only solves the problem without introducing additional complexity and possible negative consequences.
See also:
- You Don’t Need It Principle (YAGNI)
- No Silver Bullet: Essential and Subsidiary Work in Software Engineering
- No Silver Bullet: Accidental Complexity and Essential Complexity
Example:
Parkinson’s Law
Within the time limit in which the work can be completed, the workload increases until all available time is filled.
Based on the research background of bureaucracy, this law is applied to software development. The theory is that teams meet deadlines inefficiently and then rush to complete work before the deadline, making the actual deadline arbitrary.
Combine this theorem with Hofstadters-law, and you get a more pessimistic view: In order to complete the work within the specified time, the work will increase and take longer than expected.
See also:
Premature Optimization Effect
Premature optimization is the root of all evil.
In Knuth’s [“Structured Programming with goto statements”] (http://wiki.c2.com/?StructuredProgrammingWithGoToStatements) paper, he wrote: “Programmers waste a lot of time thinking about or worrying about the speed of non-critical parts of their programs. When considering debugging and maintenance, these so-called efficiency-improving practices are actually very inappropriate. We should give up small efficiency points and remind ourselves 97% of the time that premature optimization is the root of all evil. And even that critical 3% cannot be let go. “
However, premature optimization can (in short) be defined as optimizing before we know what needs to be done.
Putt’s Law
Technology is dominated by two types of people, one is pure managers and the other is pure technicians.
Putt’s law often follows Putt’s corollary:
At every technical level, over time, capabilities will be reversed.
These conclusions indicate that due to various selection criteria and trends in group organization, the working levels of technical organizations will have some technical staff, as well as some managers who do not understand the complexities and challenges. This phenomenon may be due to The Peter Principle or [The Dilbert Law] Principle)](#%e5%91%86%e4%bc%af%e7%89%b9%e6%b3%95%e5%88%99-the-dilbert-principle).
However, it should be emphasized that laws such as these are broad generalizations that may apply to some types of organizations but not others.
See also:
Reed’s Law
The utility of large networks, especially social networks, increases exponentially with the size of the network.
This law is based on graph theory, in which utility is proportional to the number of possible subgroups and will grow faster than the number of participants and the number of possible connected pairs. Odlyzko and others argue that Reed’s laws overstate the value of the system itself because they do not take into account the limits of human cognition in network effects.
See also:
The Law of Conservation of Complexity or Tesler’s Law
This law states that a certain level of complexity exists in a system and cannot be reduced.
Some of the complexity in the system is unintentional. This is due to poor construction, errors or poor modeling. This unintentional complexity can be reduced or eliminated. However, some complexity is inherent due to the inherent complexity of the problem to be solved. This complexity can be transferred, but not eliminated.
The interesting thing about this law is that even if you simplify the entire system, the inherent complexity does not decrease. It gets transferred to the user, and the user has to behave in a more complex way.
The Law of Demeter
Don’t talk to strangers.
The Law of Demeter, also known as the principle of least knowledge, is a software design principle related to object-oriented languages.
This law states that a unit of software should only talk to its immediate collaborators. For example, object A refers to object B, and object B refers to object C. Then A can directly call the method of B, but should not directly call the method of C. So if C has a method of dothing(), A should not be called directly, but instead use B.getC().doThis().
Following this law can limit the scope of code changes, making it easier to maintain and more secure in the future.
The Law of Leaky Abstractions
To some extent, all non-trivial abstractions are leaky.
Joel Spolsky (Joel Spolsky)
This law states that abstractions, often used to simplify complex systems, in some cases leak out the underlying system, causing the abstraction to exhibit unexpected behavior.
For example loading a file and reading its contents. Filesystem APIs are abstractions of lower-level kernel systems, which themselves are abstractions of the physical processes associated with changes to data on disk (or flash memory for SSDs). In most cases, abstractions that handle files (like binary data streams) will work. However, with a disk drive, sequential reading of data will be much faster than random access (due to the added overhead of page faults). But with SSD drives, this overhead does not occur. The underlying details need to be understood to handle this situation (e.g., a well-structured database index file can reduce the overhead of random access), and developers need reasonable abstractions to handle the different details.
The above example becomes more complex when more abstractions are introduced. The Linux operating system allows files to be accessed over the network, but are represented locally as normal files. If there is a network failure, this abstraction will leak.如果开发人员将这些文件视为普通文件，而不考虑它们可能会受到网络延迟和故障的影响，那么解决方案就会出错。
描述该定律的文章表明，过度依赖抽象，加上对底层过程的理解不足，实际上使得问题在某些情况下更加复杂。
参见：
真实的例子：
- Photoshop 启动缓慢：我过去遇到过一个问题，就是 Photoshop 启动缓慢，有时需要几分钟。问题好像是 Photoshop 启动时，会读取当前默认打印机的一些信息。但是，如果该打印机实际上是一台网络打印机，则可能需要很长的时间。将网络打印机与本地打印机当作同样的抽象，导致连接不良的情况下出现问题。
帕金森琐碎定理 (The Law of Triviality)
该定理显示，群体将给予更多的时间和注意力来处理琐碎的问题，而不是用来处理严肃而实质性的问题。
常见的虚构例子是委员会批准核电站的计划，他们大部分时间都在讨论自行车棚的结构，而不是电厂本身等更为重要的设计。如果没有大量的专业知识或者准备，很难给非常大的复杂主题讨论提供宝贵的意见。但是，人们希望看到更多意见。因此，他们倾向于将大量时间集中在很容易推敲，但不一定被看重的小细节上。
由上面的虚构例子产生了 Bike Shedding 的说法，以形容在琐碎细节上浪费时间这一行为。
Unix 哲学 (The Unix Philosophy)
Unix 哲学指软件组件应该很小，并专注于做一件特定的事情。将小而简单以及定义良好的单元组合在一起，而不是使用大而复杂的多用途程序，可以更轻松地构建系统。
像微服务架构这种现代实践可以认为是这种哲学的应用，其中服务很小，集中于做一件特定的事情，由简单的构建块组成复杂的行为。
Spotify 模型 (The Spotify Model)
Spotify 模型是团队和组织结构的一种方法，已被 Spotify 实验室推广开来。在此模型中，团队围绕功能而非技术进行组织。
Spotify 模型还普及了部落、行会以及章节的概念，这些是组织结构的其他组成部分。
沃德勒定律 (Wadler’s Law)
任何语言设计中，讨论下面列表中某个要素所花费的总时间与其位置成正比。
- 语义 (Semantics)
- 语法 (Syntax)
- 词法 (Lexical syntax)
- 注释语法 (Lexical syntax of comments)
（简而言之，在语义上花费一个小时，就要在注释语法上花费八个小时）。
与 帕金森琐碎定理 类似, 沃德勒定律指出，在设计语言时，与这些特征的重要性相比，花在语言结构上的时间过多。
参见：
惠顿定律 (Wheaton’s Law)
不要像个傻子一样。
威尔·惠顿 (Wil Wheaton)
这条定律由威尔 · 惠顿（曾出演过星际迷航：下一代、生活大爆炸）创造，这个简洁而有力的定律旨在专业组织内营造和谐和尊重的环境。它可以在与同事交谈、代码审查、反驳观点和批评的时候派上用场。而且通常情况下，人们之间的专业交互也同样适用。
原则
原则通常是与设计相关的准则。
乔治·伯克斯定律 (All Models Are Wrong or George Box’s Law)
All models are wrong, but some are useful. 所有的模型都是错的，但有些是有用的。
乔治·伯克斯 (George Box)
这一原则表明，所有的系统模型都是有缺陷的，但只要它们没有太多缺陷，那便有可能是有用的。这一原则源于统计学，同时也适用于科学和计算模型。
大多数软件的一个基本要求都是对某种特定系统进行建模。无论是计算机网络、资源库、社会关系图还是任何其他类型的系统，设计者都必须依据适当的细节程度来建模。过多的细节可能会导致太高的复杂度，过少的细节可能会使模型无法正常工作。
参见:
切斯特森围栏 (Chesterson’s Fence)
在了解现有情况背后的原因之前，不应该进行改进。
该原则与软件工程中的消除技术负债 (Technical debt) 相关。程序的每一行最初都是出于某种原因编写的，因此根据切斯特森围栏原则，在更改或删除代码之前，即使看起来似乎是多余的或不正确的，也应该尝试完全理解代码的上下文和含义。
该原则的名字来源于 G.K. Chesterson 的一则故事。一个男人横穿马路中央的栅栏，他向市长抱怨这道栅栏没有用还挡路，并要求拆除它。市长问他为什么要在那里建栅栏，那个人回答说不知道。市长接着说：“如果你不知道它的用途，我肯定不会让你把它拆了。你去查查它的用途，之后我可能会允许你拆掉它。 “
死海效应 (The Dead Sea Effect)
“… 那些更有才华，更有效率的 IT 工程师最有可能离开——消失 … （而那些倾向于）留下来的“剩下的人”——是最没有才华和效率的 IT 工程师。 “
Bruce F. Webster
死海效应表明，在任何一个组织中，工程师的技能、才华和效能往往与他们在公司的时间呈反比。
通常情况下，技术好的工程师很容易在其他的地方找到工作，并且他们往往也会这样做。而技能过时或技术薄弱的工程师则会留在公司，因为其他地方很难找到工作。如果这些工程师在公司里获得了加薪，他们会更愿意留在公司，因为在其他地方找到同等薪酬的工作会很有挑战性。
呆伯特法则 (The Dilbert Principle)
公司会倾向于系统地将工作能力差的员工提升到管理层，以使他们脱离工作流程。
史考特·亚当斯 (Scott Adams)
呆伯特原则是由史考特·亚当斯 (Dilbert 漫画连环画的创建者) 开发的一个管理概念，灵感来源于彼得原理。根据呆伯特原则，工作能力差的员工会被提升到管理层，从而限制他们所能造成的损害。亚当斯首先在 1995 年《华尔街日报》的一篇文章中解释了这一原则，随后在他 1996 年的商业书籍《呆伯特原则》中进行了扩展。
参见：
帕累托法则 (The Pareto Principle or The 80/20 Rule)
生活中大多数事情不是均匀分布的。
帕累托法则可以帮你认识到大多数结果来自少数投入：
- 某个软件的 80％ 代码只占了总分配时间的 20％（相反，最难的 20％ 代码部分占用了 80％ 的时间）
- 20％ 的努力产生了 80％ 的结果
- 20％ 的工作创造了 80％ 的收入
- 20％ 的错误导致了 80％ 的崩溃
- 20％ 的功能导致了 80％ 的使用量
在 20 世纪 40 年代，公认为质量控制之父的美国罗马尼亚工程师约瑟夫·朱兰博士，开始将帕累托法则应用于质量问题。
这个原则也被称为二八法则，重要的少数法则和因素稀疏原则。
现实的例子：
- 微软 2002 年的报告表明，修复最常出现的 20％ 错误，将消除 Windows 和 Office 中 80％ 的 错误和崩溃。 报告地址
舍基原理 (The Shirky Principle)
Institutions will try to preserve the problem to which they are the solution. 各机构会努力保留他们能够解决的问题。
克莱·舍基 (Clay Shirky)
舍基原理表明，复杂的解决方案——一家公司、一个行业或一项技术——可能会过于专注于他们正在解决的问题，以至于在无意中使问题本身变得永久化。这可能是有意为之（公司努力为问题找到新的细微差别，以证明继续开发解决方案是合理的），也可能是无意之举（不愿意接受和构建一个完全解决或避免问题的解决方案）。
Related content:
- “当一个人不理解自己的工作就能够获得酬劳时，那么他就很难再去了解这份工作了！ ”——厄普顿·辛克莱
- 《创新者的困境》克莱·克里斯滕森
参见:
彼得原理 (The Peter Principle)
在等级制度中，人往往会被提升到他们的“无法胜任的水平”。
劳伦斯·彼得 (Laurence J. Peter)
这是由劳伦斯·彼得提出的一个管理概念。彼得原理认为，擅长工作的人会得到提升，直到他们达到不再成功的水平 (即他们所“无法胜任的水平”)。基于此，由于他们资历更高，被公司开除的可能性较小 (除非他们表现非常糟糕)。而且他们将继续担任几乎没有本职技能的职位，即使那些原本让他们成功的能力在新工作中并无必要。
有的工程师对此特别感兴趣，它们最初从事的是深度的技术工作，但走上了管理其他工程师的职业道路——这意味着需要一个完全不同的技能树。
参见：
鲁棒性原则 (The Robustness Principle or Postel’s Law)
在自己所做的事情上要保守, 在接受别人的事情上要自由。
通常应用于服务器应用程序开发中，该原则指出，你发送给其他人的内容应尽可能最小且符合要求，并且处理不符合要求的输入。
该原则的目标是构建稳健的系统。如果可以理解意图，它们可以处理不良的输入。但是，接受错误格式的输入可能存在安全隐患，特别是此类的输入未经过充分测试。
SOLID
这是一个缩写，指的是：
- S：单一功能原则 (The Single Responsibility Principle)
- O：开闭原则 (The Open/Closed Principle)
- L：里氏替换原则 (The Liskov Substitution Principle)
- I：接口隔离原则 (The Interface Segregation Principle)
- D：依赖反转原则 (The Dependency Inversion Principle)
这些是 Object-Oriented Programming 的关键原则。诸如此类的设计原则能够帮助开发人员构建更易于维护的系统。
单一功能原则 (The Single Responsibility Principle)
每个模块或者类只应该有一项功能。
SOLID 的第一个原则。这个原则表明模块或者类只应该做一件事。实际上，这意味着对程序功能的单个小更改，应该只需要更改一个组件。例如，更改密码验证复杂性的方式应该只需要更改程序的一部分。
理论上讲，这使代码更健壮，更容易更改。知道正在更改的组件只有一个功能，这意味着测试更改更容易。使用前面的例子，更改密码复杂性组件应该只影响与密码复杂性相关的功能。变更具有许多功能的组件可能要困难得多。
参见：
开闭原则 (The Open/Closed Principle)
实体应开放扩展并关闭修改。
SOLID 的第二个原则。这个原则指出实体（可以是类、模块、函数等）应该能够使它们的行为易于扩展，但是它们的扩展行为不应该被修改。
举一个假设的例子，想象一个能够将 Markdown 转换为 HTML 的模块。如果可以扩展模块，而不修改内部模块来处理新的 markdown 特征，而无需修改内部模块，则可以认为是开放扩展。如果用户不能修改处理现有 Markdown 特征的模块，那么它被认为是关闭修改。
这个原则与面向对象编程紧密相关，让我们可以设计对象以便于扩展，但是可以避免以意想不到的方式改变其现有对象的行为。
参见：
里氏替换原则 (The Liskov Substitution Principle)
可以在不破坏系统的情况下，用子类型替换类型。
SOLID 的第三个原则。该原则指出，如果组件依赖于类型，那么它应该能够使用该类型的子类型，而不会导致系统失败或者必须知道该子类型的详细信息。
举个例子，假设我们有一个方法，读取 XML 文档。如果该方法使用基类型 file，则从 file 派生的任何内容，都能用在该方法中。 如果 file 支持反向查找，并且 xml 解析器使用该函数，但是派生类型 network file 尝试反向查找时失败，则 network file 将违反该原则。
该原则与面向对象编程紧密相关，必须仔细建模、层次结构，以避免让系统用户混淆。
参见：
接口隔离原则 (The Interface Segregation Principle)
不应强制任何客户端依赖于它不使用的方法。
SOLID 的第四个原则。该原则指出组件的消费者不应该依赖于它实际上不使用的组件函数。
举一个例子，假设我们有一个方法，读取 XML 文档。它只需要读取文件中的字节，向前移动或向后移动。如果由于一个与文件结构不相关的功能发生更改（例如更新文件安全性的权限模型），需要更新此方法，则该原则已失效。文件最好实现 可查询流 接口，并让 XML 读取器使用该接口。
该原则与面向对象编程紧密相关，其中接口，层次结构和抽象类型用于不同组件的 minimise the coupling。 Duck typing 是一种通过消除显式接口来强制执行该原则的方法。
参见：
依赖反转原则 (The Dependency Inversion Principle)
高级模块不应该依赖于低级实现。
SOLID 的第五个原则。该原则指出，更高级别的协调组件不应该知道其依赖项的详细信息。
举个例子，假设我们有一个从网站读取元数据的程序。我们假设主要组件必须知道下载网页内容的组件，以及可以读取元数据的组件。如果我们考虑依赖反转，主要组件将仅依赖于可以获取字节数据的抽象组件，然后是一个能够从字节流中读取元数据的抽象组件，主要组件不需要了解 TCP、IP、HTTP、HTML 等。
这个原则很复杂，因为它似乎可以反转系统的预期依赖性（因此得名）。实践中，这也意味着，单独的编排组件必须确保抽象类型的正确实现被使用（例如在前面的例子中，必须提供元数据读取器组件、HTTP 文件下载功能和 HTML 元标签读取器）。然后，这涉及诸如 Inversion of Control 和 Dependency Injection 之类的模式。
参见：
不要重复你自己原则 (The DRY Principle)
系统中，每一块知识都必须是单一、明确而权威的。
DRY 是 Do not Repeat Yourself 的缩写。这个原则旨在帮助开发人员减少代码的重复性，并将公共代码保存在一个地方。最初由安德鲁·亨特和戴夫·托马斯在 1999 年出版的《程序员修炼之道》中引用。
与 DRY 相反的是 WET（功能实现两次或者喜欢打字 Write Everything Twice or We Enjoy Typing）。
实际上，如果你在两个或更多的地方有相同的功能，你可以使用 DRY 原则将它们合并为一个，并在任何你需要的地方重复使用。
参见：
KISS 原则 (The KISS Principle)
保持简单和直白。
KISS 原则指明了如果大多数的系统能够保持简单而非复杂化，那么他们便能够工作在最佳状态。因此，简单性应该是设计时的关键指标，同时也要避免不必要的复杂度。这个短语最初出自 1960 年的美国海军飞机工程师凯利 · 约翰逊 (Kelly Johnson)。
这一原则的最好例证便是约翰逊给设计工程师一些实用工具的故事。那时的他们正面临着一个挑战，即他们参与设计的喷气式飞机必须能够让普通的机械师在战场上仅仅用这些工具进行维修，因此，“直白”这个词应指的是损坏的事物本身和修复用工具的复杂度两者之间的关系，而非工程师们自身的能力水平。
参见：
你不需要它原则 (YAGNI)
这是 You Aren’t Gonna Need It 的缩写。
只有当你需要某些东西的时候，才去实现它们，而不是在你预见的时候。
Ron Jeffries 是极限编程的创始人之一以及书籍《Extreme Programming Installed》的作者。
极限编程原则告诫开发人员，他们应该只实现当前所需的功能，并避免实现未来需要的功能，仅在必要时才实现。
遵守这一原则可以减小代码库大小，同时避免时间和生产力浪费在没有价值的功能上。
参见：
分布式计算的谬论 (The Fallacies of Distributed Computing)
又称 网络计算的谬误，这是一系列关于分布式计算的猜想（或者看法），这些猜想可能会引起软件开发中的失败。这些假设是：
- 网络可靠
- 延迟为零
- 带宽无限
- 网络安全
- 拓扑恒定
- 单一管理员
- 运输成本为零
- 网络为同构的
前 4 各项目由 Bill Joy 和 Tom Lyon 于 1991 左右提出。并被 James Gosling 首次归类于“网络计算的谬误”；后 L. Peter Deutsch 添加了第 5、6、7 个谬误；90 年代末，Gosling 添加了最后一个谬误。
这些内容受到了 太阳微系统 (Sun Microsystems) 内部当时所发生的事情的启发。
在设计弹性代码的时候，应该仔细考虑这些谬误，并假设其中任何一个谬误都可能引起处理分布式系统的复杂性和现实性时的逻辑缺陷。
参见:
阅读清单
如果你觉得这些概念很有趣，你可能会喜欢以下书籍。
- 《极限编程安装》谷歌阅读地址 - 涵盖极限编程的核心原则。
- 《人月神话》谷歌阅读地址、豆瓣地址 - 软件工程的经典书籍。这本书的中心主题就是布鲁克斯法则 。
- 《哥德尔、艾舍尔、巴赫：集异璧之大成》谷歌阅读地址、豆瓣地址 - 这本书很难分类。 侯世达定律 来自此书。
- 《大教堂与市集》英文维基百科 - 一本关于开源的文集，林纳斯定律 (Linus’s Law)源于此书。
- 《呆伯特原则》谷歌阅读地址 - 一本审视美国企业的漫画书，其作者创造了呆伯特法则。
- 《彼得原理》谷歌阅读地址 - 一本专注于大型组织和人员管理的挑战的漫画书，也是彼得原理的来源。
- 《计算机程序的构造和解释》谷歌阅读地址 - 如果你是 MIT 或剑桥大学的 CS、EE 学生，这是一本编程的入门书，并且被称为“人生的转折点”。
在线资源
一些有用的资源和阅读资料。
- CB Insights: 8 Laws Driving Success In Tech: Amazon’s 2-Pizza Rule, The 80/20 Principle, & More - 这是以前有趣的文章，介绍了一些对技术上产生了很大影响的定律。
相关项目
- Tip of the Day - Receive a daily hacker law/principle.
- Hacker Laws CLI - List, view and see random laws from the terminal!
- Hacker Laws Action - Adds a random Hacker Law to a pull request as a small gift for the contributor, thanks Umut Işık