hacker-laws
Laws, Theories, Patterns and Ideas that all developers should know about!
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!
I have tried to use a star rating for how 'important' a law is. The more stars, the more likely you are to hear the law referred to, and therefore the more potentially useful it is to know about it. Of course this is highly subjective, I am open to other suggestions.
The Laws
And here we go!
⭐⭐ Conway's Law
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 orientated around features or services, the software systems will also reflect this.
See also: 'The Spotify Model'.
⭐ Hofstadter's Law
It always takes longer than you expect, even when you take into account Hofstadter's Law.
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 accurately estimating how long something will take to deliver.
⭐⭐ The Law of Conservation of Complexity (Tessler'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' - is is 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 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 behaviour to be composed from simple building blocks.
⭐The Spotify Model
The Spotify Model on Spotify Labs
The Spotify Model is an approach to team and organisation structure which has been popularised by 'Spotify'. In this model, teams are organised around features, rather than technologies.
The Spotify Model also popularises the concepts of Tribes, Guilds, Chapters, which are other components of their organisation structure.