🧠 Laws, Theories, Principles and Patterns for developers and technologists.
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:
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:
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:
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:
Examples:
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 project which is already late, by adding more people, will make the delivery even later. Brooks is clear that this is an over-simplification, however, the general reasoning is that given the ramp-up time of new resources and the communication overheads, in the immediate short-term velocity decreases. Also, many tasks may not be divisible, i.e. easily distributed between more resources, meaning the potential velocity increase is also lower.
The common phrase in delivery "Nine women can't make a baby in one month" relates to Brooks' Law, in particular, the fact that some kinds of work are not divisible or parallelisable.
This is a central theme of the book 'The Mythical Man Month'.
See also:
CAP Theorem (Brewer's Theorem)
The CAP Theorem (defined by Eric Brewer) states that for a distributed data store only two out of the following three guarantees (at most) can be made:
- Consistency: when reading data, every request receives the most recent data or an error is returned
- Availability: when reading data, every request receives a non error response, without the guarantee that it is the most recent data
- Partition Tolerance: when an arbitrary number of network requests between nodes fail, the system continues to operate as expected
The core of the reasoning is as follows. It is impossible to guarantee that a network partition will not occur (see The Fallacies of Distributed Computing). Therefore in the case of a partition we can either cancel the operation (increasing consistency and decreasing availability) or proceed (increasing availability but decreasing consistency).
The name comes from the first letters of the guarantees (Consistency, Availability, Partition Tolerance). Note that it is very important to be aware that this does not relate to ACID, which has a different definition of consistency. More recently, PACELC theorem has been developed which adds constraints for latency and consistency when the network is not partitioned (i.e. when the system is operating as expected).
Most modern database platforms acknowledge this theorem implicitly by offering the user of the database the option to choose between whether they want a highly available operation (which might include a 'dirty read') or a highly consistent operation (for example a 'quorum acknowledged write').
Real world examples:
See also:
Clarke's three laws
Clarke's three laws on Wikipedia
Arthur C. Clarke, an british science fiction writer, formulated three adages that are known as Clarke's three laws. The third law is the best known and most widely cited.
These so-called laws are:
- When a distinguished but elderly scientist states that something is possible, they are almost certainly right. When they state that something is impossible, they are very probably wrong.
- The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
- Any sufficiently advanced technology is indistinguishable from magic.
Conway's Law
Conway's Law on Wikipedia
This law suggests that the technical boundaries of a system will reflect the structure of the organisation. It is commonly referred to when looking at organisation improvements, Conway's Law suggests that if an organisation is structured into many small, disconnected units, the software it produces will be. If an organisation is built more around 'verticals' which are oriented around features or services, the software systems will also reflect this.
See also:
Cunningham's Law
Cunningham's Law on Wikipedia
The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer.
According to Steven McGeady, Ward Cunningham advised him in the early 1980s: "The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer." McGeady dubbed this Cunningham's law, though Cunningham denies ownership calling it a "misquote." Although originally referring to interactions on Usenet, the law has been used to describe how other online communities work (e.g., Wikipedia, Reddit, Twitter, Facebook).
See also:
Dunbar's Number
Dunbar's Number on Wikipedia
"Dunbar's number is a suggested cognitive limit to the number of people with whom one can maintain stable social relationships— relationships in which an individual knows who each person is and how each person relates to every other person." There is some disagreement to the exact number. "... [Dunbar] proposed that humans can comfortably maintain only 150 stable relationships." He put the number into a more social context, "the number of people you would not feel embarrassed about joining uninvited for a drink if you happened to bump into them in a bar." Estimates for the number generally lay between 100 and 250.
Like stable relationships between individuals, a developer's relationship with a codebase takes effort to maintain. When faced with large complicated projects, or ownership of many projects, we lean on convention, policy, and modeled procedure to scale. Dunbar's number is not only important to keep in mind as an office grows, but also when setting the scope for team efforts or deciding when a system should invest in tooling to assist in modeling and automating logistical overhead. Putting the number into an engineering context, it is the number of projects (or normalized complexity of a single project) for which you would feel confident in joining an on-call rotation to support.
See also:
The Dunning-Kruger Effect
The Dunning-Kruger Effect on Wikipedia
If you're incompetent, you can't know you're incompetent... The skills you need to produce a right answer are exactly the skills you need to recognize what a right answer is.
(David Dunning)
The Dunning–Kruger effect is a theoretical cognitive bias which was described by David Dunning and Justin Kruger in a 1999 psychological study and paper. The study suggests that people with a low level of ability at a task are likely to overestimate their ability of the task. The proposed reason for this bias is that a sufficient awareness of the complexity of a problem or domain is required for a person to be able to make an informed opinion of their capability to work in that domain.
The Dunning-Kruger effect has sometimes been used to describe a related, but not necessarily implied effect which could be described as "The less a person understands a domain, the more they are likely to believe they can easily solve problems in that domain, as they are more likely to see the domain as simple". This more general effect is highly relevant in technology. It would suggest that people who are less familiar with a domain, such as non-technical team members or less experienced team members, are more likely to underestimate the effort required to solve a problem in this space.
As a person's understanding and experience in a domain grows, they may well encounter another effect, which is that they tend to overestimate the ability of others or underestimate their own ability, as they are have become so experienced in the domain. In all cases these effects are cognitive biases. As with any bias, an understanding that it may be present will often be sufficient to help avoid the challenges — as when there is awareness of a bias, more inputs and opinions can be included to attempt to eliminate these biases. A closely related bias is that of Illusory superiority.
Real-world examples:
Fitts' Law
Fitts' Law on Wikipedia
Fitts' law predicts 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.
The consequences of this law dictate that when designing UX or UI, interactive elements should be as large as possible and the distance between the users attention area and interactive element should be as small as possible. This has consequences on design, such as grouping tasks that are commonly used with one another close.
It also formalises the concept of 'magic corners', the corners of the screen to which a user can 'sweep' their mouse to easily hit - which is where key UI elements can be placed. The Windows Start button is in a magic corner, making it easy to select, and as an interesting contrast, the MacOS 'close window' button is not in a magic corner, making it hard to hit by mistake.
See also:
- [The information capacity of the human motor system in controlling the amplitude of movement.](https://www
这是一份精选参考资料，收录了与软件开发者和技术人员相关的知名定律、理论、原则和模式，例如 Conway's Law、CAP Theorem 和 DRY Principle。