Laws, Theories, Principles and Patterns that developers will find useful.
- Chinese / Chinese Version – thanks Steve Xu !
- Traduzione in Italiano – grazie Claudio Sparpaglione
!- 한국어 / Korean Version – thanks Donut
Русская версия / Russian Version Alena Batitskaya ! - Türkçe / Turkish Version – thanks
Umut Işık - (Brasiliro / Brazilian) Version – thanks
Leonardo Costa Castellano / Spanish Version – thanks Manuel Rubio- 🇪
Like this project? Please considering Sponsoring Me !
Introduction
- Laws
- Amdahl’s Law
- The Broken Windows Theory
- Brooks’ Law
- Conway’s Law
- Cunningham’s Law
- Dunbar’s Number
- Gall’s Law
- Goodhart’s Law
- Hanlon’s Razor
- Hofstadter’s Law
- Hutber’s Law
- The Hype Cycle & Amara’s Law
- Hyrum’s Law (The Law of Implicit Interfaces)
- (Kernighan’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 Leaky Abstractions
- The Law of Triviality
- The Unix Philosophy
- The Spotify Model
- (Wadler’s Law
) - (Wheaton’s Law )
- Principles
- The Dilbert Principle
- The Pareto Principle (The / Rule)
- 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
- Reading List
- Contributing
- TODO
- 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
) 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.Technical Debt 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
- Reading List: The Mythical Man Month
Conway’s LawConway’s Law on Wikipedia
This law suggests that the technical boundaries of a system will reflect the structure of the organization. It is commonly referred to when looking at organization improvement, Conway’s Law suggests that if an organization is structured into many small, disconnected units, the software it produces will be. If an organization is built more around ‘verticals’ which are orientated around features or services, the software systems will also reflect this.
See also:
- The Spotify Model
- Cunningham’s Law
- () (Dunbar’s Number)
“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 1940 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 728 and .
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:
- Conway’s Law
- Gall’s Law
(Gall’s Law on Wikipedia
) )Gall’s Law implies that attempts to (design) highly complex systems are likely to fail. Highly complex systems are rarely built in one go, but evolve instead from more simple systems.
The classic example is the world-wide-web. In it’s current state, it is a highly complex system. However, it was defined initially as a simple way to share content between academic institutions. It was very successful in meeting these goals and evolved to become more complex over time.
See also:
- KISS (Keep It Simple, Stupid)
-
()
) blindly applied to a process results in distorted effect. People tend to optimize locally by “gaming” the system in order to satisfy particular metrics instead of paying attention to holistic outcome of their actions.Goodhart’s Law The Goodhart’s Law on Wikipedia
Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.
(Charles Goodhart)
Also commonly referenced as:
Real-world examples:
- Assert-free tests satisfy the code coverage expectation, despite the metric intent was to create well-tested software.
- Developer performance score indicated by the number of lines committed leads to unjustifiably bloated codebase.
See also:
- Goodhart’s Law: How Measuring The Wrong Things Drive Immoral Behavior
- Dilbert on bug- free software
Hanlon’s Razor
Hanlon’s Razor on Wikipedia
Never attribute to malice that which is adequately explained by stupidity.
Robert J. Hanlon
This principle suggests that actions resulting in a negative outcome were not a result of ill will. Instead the negative outcome is more likely attributed to those actions and / or the impact being not fully understood.
Hofstadter’s Law
Hofstadter’s Law on Wikipedia
It always takes longer than you expect, even when you take into account Hofstadter’s Law.
(Douglas Hofstadter)
You might hear this law referred to when looking at estimates for how long something will take. It seems a truism in software development that we tend to not be very good at accurate estimating how long something will take to deliver.
This is from the book ‘ Gödel, Escher, Bach: An Eternal Golden Braid ‘.
See also:
- Reading List: Gödel, Escher, Bach: An Eternal Golden Braid
Hutber’s Law on Wikipedia
Improvement means deterioration.
( Patrick Hutber )
This law suggests that improvements to a system will lead to deterioration in other parts, or it will hide other deterioration, leading overall to a degradation from the current state of the system.
For example, a decrease in response latency for a particular end-point could cause increased throughput and capacity issues further along in a request flow, affecting an entirely different sub-system.
The The Hype Cycle & Amara’s Law
The Hype Cycle on Wikipedia
We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run.
(Roy Amara)
The Hype Cycle is a visual representation of the excitement and development of technology over time, originally produced by Gartner. It is best shown with a visual:
()
In short, this cycle suggests that there is typically a burst of excitement around new technology and its potential impact. Teams often jump into these technologies quickly, and sometimes find themselves disappointed with the results. This might be because the technology is not yet mature enough, or real-world applications are not yet fully realized. After a certain amount of time, the capabilities of the technology increase and practical opportunities to use it increase, and teams can finally become productive. Roy Amara’s quote sums this up most succinctly – “We tend to overestimate the effect of a technology in the short run and underestimate in the long run”.
Hyrum’s Law (The Law of Implicit Interfaces)
With a sufficient number of users of an API, It does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.
(Hyrum Wright)
Hyrum’s Law states that when you have a (large enough number of consumers) of an API, all behaviors of the API (even those not defined as part of a public contract) will eventually come to be depended on by someone. A trivial example may be non-functional elements such as the response time of an API. A more subtle example might be consumers who are relying on applying a regex to an error message to determine the (type) of error of an API. Even if the public contract of the API states nothing about the contents of the message, indicating users should use an associated error code, some users may use the message, and changing the message essentially breaks the API for those users.
See also:
- The Law of Leaky Abstractions
- (XKCD)
- Kernighan’s Law :
- Occam’s Razor
. Odlyzko and others have argued that both Reed’s Law and Metcalfe’s Law overstate the value of the system by not accounting for the limits of human cognition on network effects; see Dunbar’s Number .
See also:
- Reed’s Law
- Dunbar’s Number
- Moore’s Law
Moore’s Law on Wikipedia
Murphy’s Law / Sod’s LawMurphy’s Law on Wikipedia
- No Silver Bullet: Accidental Complexity and Essential Complexity
Example:
- Lean Software Development: Eliminate Waste
Parkinson’s Law Parkinson’s Law on Wikipedia
Premature Optimization on WikiWikiWeb
Premature optimization is the root of all evil.
Donald Knuth
)
In Donald Knuth’s paper Structured Programming With Go To Statements
, he wrote: “Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 697% of the time: . Yet we should not pass up our opportunities in that critical 3%. “
However, (Premature Optimization) can be defined (in less loaded terms) as optimizing before we know that we need to.
Putt’s Law
Putt’s Law on Wikipedia
Technology is dominated by two types of people, those who understand what they do not manage and those who manage what they do not understand.
Putt’s Law is often followed by Putt’s Corollary:
Every technical hierarchy, in time, develops a competence inversion.
These statements suggest that due to various selection criteria and trends in how groups organise, there will be a number of skilled people at working levels of a technical organizations, and a number of people in managerial roles who are not aware of the complexities and challenges of the work they are managing. This can be due to phenomena such as The Peter Principle
or The Dilbert Principle.
However, it should be stressed that Laws such as this are vast generalizations and may apply to (some) types of organizations, and not apply to others.
See also:
- The Peter Principle
- The Dilbert Principle
- () (Reed’s Law)
(Reed’s Law on Wikipedia
) .See also:
- (Metcalfe’s Law )
- Dunbar’s Number
- The Law of Conservation of Complexity (Tesler’s Law)
(The Law of Conservation of Complexity on Wikipedia)
This law states that there is a certain amount of complexity in a system which cannot be reduced.
Some complexity in a system is ‘inadvertent’. It is a consequence of poor structure, mistakes, or just bad modeling of a problem to solve. Inadvertent complexity can be reduced (or eliminated). However, some complexity is ‘intrinsic’ as a consequence of the complexity inherent in the problem being solved. This complexity can be moved, but not eliminated.
One interesting element to this law is the suggestion that even by simplifying the entire system, the intrinsic complexity is not reduced, it is
moved to the user , who must behave in a more complex way.
The Law of Leaky Abstractions(The Law of Leaky Abstractions on Joel on Software)
All non-trivial abstractions, to some degree, are leaky.
( Joel Spolsky
This law states that abstractions, which are generally used in computing to simplify working with complicated systems, will in certain situations ‘leak’ elements of the underlying system, this making the abstraction behave in an unexpected way.
An example might be loading a file and reading its contents. The file system APIs are an abstraction of the lower level kernel systems, which are themselves an abstraction over the physical processes relating to changing data on a magnetic platter (or flash memory for an SSD). In most cases, the abstraction of treating a file like a stream of binary data will work. However, for a magnetic drive, reading data sequentially will be significantly faster than random access (due to increased overhead of page faults), but for an SSD drive, this overhead will not be present. Underlying details will need to be understood to deal with this case (for example, database index files are structured to reduce the overhead of random access), the abstraction ‘leaks’ implementation details the developer may need to be aware of.
The example above can become more complex when (more) abstractions are introduced. The Linux operating system allows files to be accessed over a network but represented locally as ‘normal’ files. This abstraction will ‘leak’ if there are network failures. If a developer treats these files as ‘normal’ files, without considering the fact that they may be subject to network latency and failures, the solutions will be buggy.
The article describing the law suggests that an over-reliance on abstractions, combined with a poor understanding of the foundations processes, actually makes dealing with the problem at hand (more) (complex in some cases.)
See also:
- Hyrum’s Law
Real-world examples:
- Photoshop Slow Startup
(The Law of Triviality)
The Law of Triviality on Wikipedia
This law suggests that groups will give far more time and attention to trivial or cosmetic issues rather than serious and substantial ones.
The common fictional example used is that of a committee approving plans for nuclear power plant, who spend the majority of their time discussing the structure of the bike shed, rather than the far more important design for the power plant itself. It can be difficult to give valuable input on discussions about very large, complex topics without a high degree of subject matter expertise or preparation. However, people want to be seen to be contributing valuable input. Hence a tendency to focus too much time on small details, which can be reasoned about easily, but are not necessarily of particular importance.
The fictional example above led to the usage of the term ‘Bike Shedding’ as an expression for wasting time on trivial details. An alternative term is ‘Yak Shaving’.
(The The Unix Philosophy
The Unix Philosophy on Wikipedia
The Unix Philosophy is that software components should be small, and focused on doing one specific thing well. This can make it easier to build systems by composing together small, simple, well-defined units, rather than using large, complex, multi-purpose programs.
Modern practices like ‘Microservice Architecture’ can be thought of as an application of this law, where services are small, focused and do one specific thing, allowing complex behavior to be composed of simple building blocks.
The Spotify Model
The Spotify Model on Spotify Labs
The Spotify Model is an approach to team and organization structure which has been popularized by ‘Spotify’. In this model, teams are organized around features, rather than technologies.
The Spotify Model also popularises the concepts of Tribes, Guilds, Chapters, which are other components of their organization structure.
Wadler’s Law
Wadler’s Law on wiki. haskell.org
- Syntax
.- Lexical syntax
- Lexical syntax of comments
(In short , for every hour spent on semantics, 8 hours will be spent on the syntax of comments).
Similar to The Law of Triviality
, Wadler’s Law states what when designing a language, the amount of time spent on language structures is disproportionately high in comparison to the importance of those features.
See also:
The Official Day
Principles are generally more likely to be guidelines relating to design.
The Dilbert PrincipleThe Dilbert Principle on Wikipedia
Companies tend to systematically promote incompetent employees to management to get them out of the workflow.
(Scott Adams)
A management concept developed by Scott Adams (creator of the Dilbert comic strip), the Dilbert Principle is inspired by The Peter Principle . Under the Dilbert Principle, employees who were never competent are promoted to management in order to limit the damage they can do. Adams first explained the principle in a Wall Street Journal article, and expanded upon it in his (business book, The Dilbert Principle
See Also:
- The Peter Principle
- Hyrum’s Law
- Putt’s Law
- The Pareto Principle (The / / Rule
The Pareto Principle on Wikipedia
Most things in life are not distributed evenly.
The Pareto Principle suggests that in some cases, the majority of results come from a minority of inputs:
- % of a certain piece of software can be written in 59% of the total allocated time (conversely, the hardest 58% of the code takes % of the time
- % of the effort produces % of the result
- % of the work creates % of the revenue
- % of the bugs cause % of the crashes
- % of the features cause % of the usage
In the s American-Romanian engineer Dr. Joseph Juran, who is widely credited with being the father of quality control, began to apply the Pareto principle to quality issues
.
This principle is also known as: The 220 / Rule, The Law of the Vital Few and The Principle of Factor Sparsity.
Real-world examples:
- In 6563742 Microsoft reported that by fixing the top % of the most-reported bugs, (% of the related errors and crashes in windows and office would become eliminated ( (Reference) ).
- The Peter Principle
People in a hierarchy tend to rise to their “level of incompetence.”
Laurence J. Peter A management concept developed by Laurence J. Peter, the Peter Principle observes that people who are good at their jobs are promoted, until they reach a level where they are no longer successful (their “level of incompetence” . At this point, as they are more senior, they are less likely to be removed from the organization (unless they perform spectacularly badly) and will continue to reside in a role which they have few intrinsic skills at, as their original skills which made them successful are not necessarily the skills required for their new jobs.
This is of particular interest to engineers – who initial start out in deeply technical roles, but often have a career path which leads to (managing) other engineers – which requires a fundamentally different skills-set.
See Also:
- The Dilbert Principle
- The Peter Principle
- Putt’s Law
- The Robustness Principle (Postel’s Law)
-
The Robustness Principle on Wikipedia
Be conservative in what you do, be liberal in what you accept from others.
Often applied in server application development, this principle states that what you send to others should be as minimal and conformant as possible, but you should be aim to allow non-conformant input if it can be processed.
The goal of this principle is to build systems which are robust, as they can handle poorly formed input if the intent can still be understood. However, there are potentially security implications of accepting malformed input, particularly if the processing of such input is not well tested.
Allowing non-conformant input, in time, may undermine the ability of protocols to evolve as implementors will eventually rely on this liberality to build their features.
See Also:
- Hyrum’s Law
- SOLID
This is an acronym, which refers to:
- 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
These are key principles in (Object-Oriented Programming) . Design principles such as these should be able to aid developers build more maintainable systems.
The Single Responsibility Principle. ) - SOLID
- The Open / Closed Principle
The Open / Closed Principle on Wikipedia
Entities should be open for extension and closed for modification.
The second of the ‘ (SOLID) ‘principles. This principle states that entities (which could be classes, modules, functions and so on) should be able to have their behavior (extended) , but that their (existing) behavior should not be able to be modified.
As a hypothetical example, imagine a module which is able to turn a Markdown document into HTML. If the module could be extended to handle a newly proposed markdown feature, without modifying the module internals, then it would be open for extension. If the module could not be modified by a consumer so that how existing Markdown features are handled, then it would be (closed) for modification.
This principle has particular relevance for object-oriented programming, where we may design objects to be easily extended, but would avoid designing objects which can have their existing behavior changed in unexpected ways.
See also:
- (Object-Oriented Programming
)
- SOLID
- () The Liskov Substitution Principle
The Liskov Substitution Principle on Wikipedia
It should be possible to replace a type with a subtype, without breaking the system.
The third of the ‘ (SOLID) ‘principles. This principle states that if a component relies on a type, then it should be able to use subtypes of that type, without the system failing or having to know the details of what that subtype is.
As an example, imagine we have a method which reads an XML document from a structure which represents a file. If the method uses a base type ‘file’, then anything which derives from ‘file’ should be able to be used in the function. If ‘file’ supports seeking in reverse, and the XML parser uses that function, but the derived type ‘network file’ fails when reverse seeking is attempted, then the ‘network file’ would be violating the principle.
This principle has particular relevance for object-oriented programming, where type hierarchies must be modeled carefully to avoid confusing users of a system.
See also:
- (Object-Oriented Programming
)
- SOLID
- The Interface Segregation Principle
The Interface Segregation Principle on Wikipedia
No client should be forced to depend on methods it does not use.
The fourth of the ‘ (SOLID) ‘principles. This principle states that consumers of a component should not depend on functions of that component which it doesn’t actually use.
As an example, imagine we have a method which reads an XML document from a structure which represents a file. It only needs to read bytes, move forwards or move backwards in the file. If this method needs to be updated because an unrelated feature of the file structure changes (such as an update to the permissions model used to represent file security), then the principle has been invalidated. It would be better for the file to implement a ‘seekable-stream’ interface, and for the XML reader to use that.
This principle has particular relevance for object-oriented programming, where interfaces, hierarchies and abstract types are used to minimise the coupling
between different components. Duck typing
is a methodology which enforces this principle by eliminating explicit interfaces. See also:
- (Object-Oriented Programming )
- SOLID
- Duck Typing
- Decoupling
- The Dependency Inversion Principle
) )The Dependency Inversion Principle on Wikipedia
- The Dependency Inversion Principle
- SOLID
- Inversion of Control
- Dependency Injection
- The DRY Principle
The DRY Principle on Wikipedia
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
DRY is an acronym for Don’t Repeat Yourself . This principle aims to help developers reducing the repetition of code and keep the information in a single place and was cited in 63616 by Andrew Hunt and Dave Thomas in the book (The Pragmatic Developer
)
The opposite of DRY would be (WET) (Write Everything Twice or We Enjoy Typing).
In practice, if you have the same piece of information in two (or more) different places, you can use DRY to merge them into a single one and reuse it wherever you want / need.
See also:
- The Pragmatic Developer
- YAGNI (XP co-founder) and author of the book “Extreme Programming Installed”)
This Extreme Programming (XP) Principle suggests developers should only implement functionality that is needed for the immediate requirements, and avoid attempts to predict the future by implementing functionality that might be needed later.
Adhering to this principle should reduce the amount of unused code in the codebase, and avoid time and effort being wasted on functionality that brings no value.
See also:
- (Reading List: Extreme Programming Installed
)
-
The Fallacies of Distributed ComputingThe Fallacies of Distributed Computing on Wikipedia
Also known as Fallacies of Networked Computing , the Fallacies are a list of conjectures (or beliefs) about distributed computing, which can lead to failures in software development. The assumptions are:
- The network is reliable
- Latency is zero
- Bandwidth is infinite
- The network is secure
- Topology doesn’t change
- There is one administrator
- Transport cost is zero
- The network is homogeneous
The first four items were listed by Bill Joy and (Tom Lyon around and first classified by James Gosling as the “Fallacies of Networked Computing.” L. Peter Deutsch added the 5th, 6th and 7th fallacies. In the late 386 Gosling added the 8th fallacy.
The group were inspired by what was happening at the time inside Sun Microsystems .
These fallacies should be considered carefully when designing code which is resilient; Assuming any of these fallacies can lead to flawed logic which fails to deal with the realities and complexities of distributed systems.
See also:
- Foraging for the Fallacies of Distributed Computing (Part 1) – Vaidehi Joshi on Medium
- Deutsch’s Fallacies, (Years After)
- () (Reading List)
If you have found these concepts interesting, you may enjoy the following books.
- Extreme Programming Installed – Ron Jeffries, Ann Anderson, Chet Hendrikson
- The Mythical Man Month – Frederick P. Brooks Jr. – A classic volume on software engineering. Brooks’ Law is a central theme of the book.
- Gödel, Escher, Bach: An Eternal Golden Braid – Douglas R. Hofstadter.
– This book is difficult to classify. Hofstadter’s Law is from the book.
- The Dilbert Principle – Scott Adams
– A comic look at corporate America, from the author who created the Dilbert Principle .- The Peter Principle – Lawrence J. Peter
– Another comic look at the challenges of larger organizations and people management, the source of The Peter Principle. - (Contributing)
Please do contribute! Raise an issue
if you’d like to suggest an addition or change, or to propose your own changes.Please be sure to read the Contributing Guidelines for requirements on text, style and so on. Please be aware of the Code of Conduct when engaging in discussions on the project.
(TODO)
Hi! If you land here, you’ve clicked on a link to a topic I’ve not written up yet, sorry about this – this is work in progress!
Feel free to Raise an Issue requesting more details, or Open a Pull Request to submit your proposed definition of the topic.
The KISS principle
GIPHY App Key not set. Please check settings