Showing preview only (702K chars total). Download the full file or copy to clipboard to get everything.
Repository: dwmkerr/hacker-laws
Branch: main
Commit: f13e2dc70f29
Files: 40
Total size: 679.5 KB
Directory structure:
gitextract_45dvjnqv/
├── .all-contributorsrc
├── .github/
│ ├── CHANGELOG.md
│ ├── CODE_OF_CONDUCT.md
│ ├── FUNDING.yml
│ ├── contributing.md
│ ├── makefile
│ ├── pull_request_template.md
│ ├── release-please-config.json
│ ├── release-please-manifest.json
│ ├── website/
│ │ ├── backup/
│ │ │ ├── ideas.md
│ │ │ ├── index2.html
│ │ │ ├── index3.html
│ │ │ └── index4.html
│ │ ├── generate.py
│ │ ├── makefile
│ │ ├── requirements.txt
│ │ └── src/
│ │ ├── index.html.jinja
│ │ ├── script.js
│ │ └── styles.css
│ └── workflows/
│ └── cicd.yaml
├── .gitignore
├── LICENSE
├── README.md
├── assets/
│ ├── banner.psd
│ ├── diagrams.bmpr
│ └── site/
│ ├── index.html
│ ├── index2.html
│ ├── index3.html
│ └── index4.html
├── scripts/
│ └── prepare-markdown-for-ebook.sh
└── translations/
├── es-ES.md
├── fr.md
├── id.md
├── it-IT.md
├── jp.md
├── lv.md
├── pl.md
├── pt-BR.md
├── tr.md
└── vi.md
================================================
FILE CONTENTS
================================================
================================================
FILE: .all-contributorsrc
================================================
{
"files": [
"README.md"
],
"imageSize": 100,
"commit": false,
"commitType": "docs",
"commitConvention": "angular",
"contributors": [
{
"login": "hemmatt",
"name": "Amir Hemmati",
"avatar_url": "https://avatars.githubusercontent.com/u/22114089?v=4",
"profile": "https://github.com/hemmatt",
"contributions": [
"doc"
]
}
],
"contributorsPerLine": 7,
"skipCi": true,
"repoType": "github",
"repoHost": "https://github.com",
"projectName": "hacker-laws",
"projectOwner": "dwmkerr"
}
================================================
FILE: .github/CHANGELOG.md
================================================
# Changelog
## [0.5.0](https://github.com/dwmkerr/hacker-laws/compare/v0.4.0...v0.5.0) (2026-02-06)
### Features
* add Jevons' Paradox ([4652447](https://github.com/dwmkerr/hacker-laws/commit/46524475b67a7b1766ba1e325ccff5f90e1738f8))
* add Jevons' Paradox ([607feeb](https://github.com/dwmkerr/hacker-laws/commit/607feeb3cb078454124f5507695ff4cf624026e4)), closes [#430](https://github.com/dwmkerr/hacker-laws/issues/430)
### Bug Fixes
* broken all-contributors badge link ([ff24778](https://github.com/dwmkerr/hacker-laws/commit/ff24778aa8e3fda0eb514b1355eaaf6cdee63c54))
* convert badge to HTML for proper rendering ([f79f2c8](https://github.com/dwmkerr/hacker-laws/commit/f79f2c83c5886736e1de33714e2f4326bf71b2b7))
* remove all-contributors badge ([872a758](https://github.com/dwmkerr/hacker-laws/commit/872a7588b9042b3ac80ae5a7cea0b8b1e4877f71))
## [0.4.0](https://github.com/dwmkerr/hacker-laws/compare/v0.3.2...v0.4.0) (2025-12-29)
### Features
* add The Stochastic Parrot ([bd1f1f9](https://github.com/dwmkerr/hacker-laws/commit/bd1f1f92d680dd355c993375cd71f81f81f9cfc6))
* add The Stochastic Parrot ([286e57a](https://github.com/dwmkerr/hacker-laws/commit/286e57a0e6017845d811072d2e49b7b0c73619da))
### Bug Fixes
* correct mistranslation of Hyrum’s Law in Japanese ([ab076b3](https://github.com/dwmkerr/hacker-laws/commit/ab076b3c638460b1c792ef676b902ca74be3c763))
## [0.3.2](https://github.com/dwmkerr/hacker-laws/compare/v0.3.1...v0.3.2) (2025-03-31)
### Bug Fixes
* update ebook download link ([4546562](https://github.com/dwmkerr/hacker-laws/commit/454656237d9508c8fadafffbc1c1286fc134f8cf))
## [0.3.1](https://github.com/dwmkerr/hacker-laws/compare/v0.3.0...v0.3.1) (2025-03-31)
### Bug Fixes
* effective shell links ([6353fe4](https://github.com/dwmkerr/hacker-laws/commit/6353fe4b8f044456d66dac0af950e41989c56c5a))
## [0.3.0](https://github.com/dwmkerr/hacker-laws/compare/v0.2.1...v0.3.0) (2025-03-31)
### Features
* add Koomey's Law ([dcdcfdf](https://github.com/dwmkerr/hacker-laws/commit/dcdcfdfc25ee121b6bcb931a71e185fa7ffeedcd))
## [0.2.1](https://github.com/dwmkerr/hacker-laws/compare/v0.2.0...v0.2.1) (2025-03-31)
### Bug Fixes
* remove frontmatter ([2140429](https://github.com/dwmkerr/hacker-laws/commit/2140429b959a8284b452c3fa05e1c9fd03e5ebab))
## [0.2.0](https://github.com/dwmkerr/hacker-laws/compare/v0.1.0...v0.2.0) (2025-03-31)
### Features
* 90-90 rule ([4477907](https://github.com/dwmkerr/hacker-laws/commit/44779074caa6495198214100e5bd0a886cc1e680))
* add section for Kerckhoff's principle ([5f74607](https://github.com/dwmkerr/hacker-laws/commit/5f74607c63d3a76009ec0546ba515f8f7c1d3864))
* add ukranian language to README ([#320](https://github.com/dwmkerr/hacker-laws/issues/320)) ([015d251](https://github.com/dwmkerr/hacker-laws/commit/015d25197f808d66c4dfebcdd0b54675af6a3eae)), closes [#236](https://github.com/dwmkerr/hacker-laws/issues/236)
* Dunning Kruger Effect ([3dbc237](https://github.com/dwmkerr/hacker-laws/commit/3dbc237c1f1c59e809969320cc0ae4347a4b45c3))
* Dunning-Kruger Effect ([#318](https://github.com/dwmkerr/hacker-laws/issues/318)) ([34c38d8](https://github.com/dwmkerr/hacker-laws/commit/34c38d87edba4b0e36d2ad9488b97d0c77f9b550))
* **pages:** update index.html and pages.yaml for deployment ([beb3d57](https://github.com/dwmkerr/hacker-laws/commit/beb3d57a6a5a3a38aa9e692ed13eb01060b85ded))
* principle of least astonishment ([4be4827](https://github.com/dwmkerr/hacker-laws/commit/4be482731b6a6009453af7d303d3cd2470a2e73e))
* principle of least astonishment ([e4662cb](https://github.com/dwmkerr/hacker-laws/commit/e4662cbc27d04fb968220837633034420b7fb11a))
* the scout rule ([716aef8](https://github.com/dwmkerr/hacker-laws/commit/716aef807e758bd8df976f323089db525da9f708))
* the scout rule ([c6fccf4](https://github.com/dwmkerr/hacker-laws/commit/c6fccf4978d9483637fba8c7887127abad3de581)), closes [#144](https://github.com/dwmkerr/hacker-laws/issues/144)
* twyman's law ([b9ad4c6](https://github.com/dwmkerr/hacker-laws/commit/b9ad4c6f99f991a1bda9a2cfdddef62787e6ae82))
### Bug Fixes
* correct facebook link on website ([6f9b1e3](https://github.com/dwmkerr/hacker-laws/commit/6f9b1e33345bc1332428f0fba8c7aa2900147500))
* correct formatting around quote ([d83d439](https://github.com/dwmkerr/hacker-laws/commit/d83d439df89e8af50ae53bafa3a791f8d92a6991))
* Fix section's links ([#317](https://github.com/dwmkerr/hacker-laws/issues/317)) ([7b341fc](https://github.com/dwmkerr/hacker-laws/commit/7b341fc0d205f076e25ff8fedb972e652201c3c6))
* image paths ([692b7cc](https://github.com/dwmkerr/hacker-laws/commit/692b7cca1a97eb62384db170297b504f51ea408e))
* remove superfluous 'is' ([3b78ae6](https://github.com/dwmkerr/hacker-laws/commit/3b78ae65f02fca457bb8adbf113135e1ed042a46))
================================================
FILE: .github/CODE_OF_CONDUCT.md
================================================
# Contributor Covenant Code of Conduct
## Our Pledge
In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to making participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, sex characteristics, gender identity and expression,
level of experience, education, socio-economic status, nationality, personal
appearance, race, religion, or sexual identity and orientation.
## Our Standards
Examples of behavior that contributes to creating a positive environment
include:
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or
advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic
address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable
behavior and are expected to take appropriate and fair corrective action in
response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to this Code of Conduct, or to ban temporarily or
permanently any contributor for other behaviors that they deem inappropriate,
threatening, offensive, or harmful.
## Scope
This Code of Conduct applies both within project spaces and in public spaces
when an individual is representing the project or its community. Examples of
representing a project or community include using an official project e-mail
address, posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a project may be
further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting the project team at dwmkerr@gmail.com. All
complaints will be reviewed and investigated and will result in a response that
is deemed necessary and appropriate to the circumstances. The project team is
obligated to maintain confidentiality with regard to the reporter of an incident.
Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good
faith may face temporary or permanent repercussions as determined by other
members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
[homepage]: https://www.contributor-covenant.org
For answers to common questions about this code of conduct, see
https://www.contributor-covenant.org/faq
================================================
FILE: .github/FUNDING.yml
================================================
# Support 'GitHub Sponsors' funding.
github: dwmkerr
================================================
FILE: .github/contributing.md
================================================
# Contributing Guidelines
<!-- vim-markdown-toc GFM -->
- [Goal of the Project](#goal-of-the-project)
- [Example Law: The Law of Leaky Abstractions](#example-law-the-law-of-leaky-abstractions)
- [Translations](#translations)
- [How do I know if a law is relevant?](#how-do-i-know-if-a-law-is-relevant)
- [How do I know if a law is 'well known' enough?](#how-do-i-know-if-a-law-is-well-known-enough)
- [Use of Images](#use-of-images)
- [Developer Guide](#developer-guide)
<!-- vim-markdown-toc -->
## Goal of the Project
The goal of this project is to have a set of _concise_ definitions to laws, principles, methodologies and patterns which hackers will find useful. They should be:
1. Short - one or two paragraphs.
2. Include the original source.
3. Quote the law if possible, with the author's name.
4. Link to related laws in the 'See also' section.
5. Include real-world examples if possible in the 'Real-world examples' section.
Some other tips:
- It is fine to include laws which are humorous or not serious.
- If a law does not obviously apply to development or coding, include a paragraph explaining the relevance to technologists.
- Don't worry about managing the table of contents, I can generate it.
- Feel free to include images, but aim to keep it down to one image per law.
- Be careful not to copy-and-paste content (unless it is explicitly quoted), as it might violate copyright.
- Include hyperlinks to referenced material.
- Do not advocate for the law, or aim to be opinionated on the correctness or incorrectness of the law, as this repository is simply the descriptions and links.
- Avoid 'you' when writing. For example, prefer "This law suggests refactoring should be avoided when..." rather than "you should avoid refactoring when...". This keeps the style slightly more formal and avoids seeming like advocation of a law.
An example law is shown below, which covers most of the key points:
---
## Example Law: The Law of Leaky Abstractions
[The Law of Leaky Abstractions on Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/)
> 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 underlying processes, actually makes dealing with the problem at hand _more_ complex in some cases.
See also:
- [Hyrum's Law](#hyrums-law-the-law-of-implicit-interfaces)
Real-world examples:
- [Photoshop Slow Startup](https://forums.adobe.com/thread/376152) - an issue I encountered in the past. Photoshop would be slow to startup, sometimes taking minutes. It seems the issue was that on startup it reads some information about the current default printer. However, if that printer is actually a network printer, this could take an extremely long time. The _abstraction_ of a network printer being presented to the system similar to a local printer caused an issue for users in poor connectivity situations.
## Translations
We are currently using [GitLocalize](https://gitlocalize.com) to handle translations. This provides features to make it easier for people to manage translations as changes come in:
If you would like to moderate a language, please follow the steps below:
1. Log in to [Git Localize](https://gitlocalize.com) with your GitHub account, this will create a GitLocalize account for you.
0. [Open an Issue](https://github.com/dwmkerr/hacker-laws/issues/new) with the name of the language you would like to moderate/translate.
0. [Open a Pull Request](https://github.com/dwmkerr/hacker-laws/compare) that adds your details and the language details to the [Translators](https://github.com/dwmkerr/hacker-laws#translations) section of the README.
3. I will then make you a moderator of the language and ensure the language is listed properly.
Thanks!
## How do I know if a law is relevant?
In general, it should be reasonably applicable to the world of computer sciences, IT or coding in general.
## How do I know if a law is 'well known' enough?
A good test is 'If I search for it on Google, will I find it in the first few results?'.
## Use of Images
Please make sure to attribute images properly if you are referencing them. Also, include a white background, as some viewers will be viewing the site in 'Dark Mode' which can make images with a transparent background difficult to read.
## Developer Guide
Where possible, anything which is not the core `README.md` file is kept in the `.github/` folder to keep the landing page for the repository as clean as possible.
To use the makefile, pass its path explicitly, e.g:
```bash
make -f .github/makefile
```
Or create an alias:
```bash
alias hlmake="make -f .github/makefile"
================================================
FILE: .github/makefile
================================================
default: help
.PHONY: help
help: # Show help for each of the Makefile recipes.
@grep -E '^[a-zA-Z0-9 -]+:.*#' Makefile | sort | while read -r l; do printf "\033[1;32m$$(echo $$l | cut -f 1 -d':')\033[00m:$$(echo $$l | cut -f 2- -d'#')\n"; done
.PHONY: prepare-markdown
prepare-markdown: # Prepare the markdown for PDF output.
./scripts/prepare-markdown-for-ebook.sh "README.md" "hacker-laws.md"
.PHONY: create-pdf
create-pdf: # Create the PDF.
docker run --rm \
--platform linux/amd64 \
-v ${PWD}:/data \
pandoc/latex:3.6 \
-V toc-title:"Table Of Contents" \
--toc \
--pdf-engine=lualatex \
--standalone \
--output hacker-laws.pdf \
hacker-laws.md
================================================
FILE: .github/pull_request_template.md
================================================
**Pull Request Checklist**
Please double check the items below!
- [ ] I have read the [Contributor Guidelines](https://github.com/dwmkerr/hacker-laws/blob/master/.github/contributing.md).
- [ ] I have not directly copied text from another location (unless explicitly indicated as a quote) or violated copyright.
- [ ] I have linked to the original Law.
- [ ] I have quote the law (if possible) and the author's name (if possible).
- [ ] I am happy to have my changes merged, so that I appear as a contributor, but also the text altered if required to keep the language consistent in the project.
And don't forget:
- I can handle the table of contents, feel free to leave it out.
- Check to see if other laws should link back to the law you have added.
- Include your **Twitter Handle** if you want me to include you when tweeting this update!
================================================
FILE: .github/release-please-config.json
================================================
{
"release-type": "simple",
"bump-minor-pre-major": true,
"packages": {
".": {
"release-type": "simple",
"extra-files": [
{
"type": "generic",
"path": "README.md"
}
],
"changelog-path": ".github/CHANGELOG.md"
}
}
}
================================================
FILE: .github/release-please-manifest.json
================================================
{
".": "0.5.0"
}
================================================
FILE: .github/website/backup/ideas.md
================================================
================================================
FILE: .github/website/backup/index2.html
================================================
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Hacker Laws</title>
<!-- Bootstrap CSS -->
<link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css" rel="stylesheet" />
<!-- Bootstrap Icons -->
<link href="https://cdn.jsdelivr.net/npm/bootstrap-icons@1.10.5/font/bootstrap-icons.css" rel="stylesheet" />
<style>
/* Soft pastel parchment background */
body {
background-color: #fdf6e3;
color: #333;
padding-top: 70px; /* to account for sticky navbar */
}
/* Navbar customization */
.navbar-custom {
background-color: #ffffff;
box-shadow: 0 2px 4px rgba(0, 0, 0, 0.1);
}
/* Header styling */
header h1 {
font-size: 2.5rem;
font-weight: bold;
}
header p.lead {
font-size: 1.25rem;
color: #555;
}
/* Law section container */
.law-section {
margin-bottom: 2rem;
padding: 1.5rem;
background-color: #fff;
border-radius: 5px;
box-shadow: 0 2px 5px rgba(0, 0, 0, 0.1);
}
/* Social sharing icons */
.social-sharing a {
margin-right: 0.75rem;
font-size: 1.2rem;
color: #555;
text-decoration: none;
}
.social-sharing a:hover {
color: #000;
}
/* Back to top link styling */
.back-to-top a {
font-size: 0.9rem;
text-decoration: none;
color: #007bff;
}
.back-to-top a:hover {
text-decoration: underline;
}
</style>
</head>
<body id="top">
<!-- Sticky Navbar -->
<nav class="navbar navbar-expand-lg navbar-custom fixed-top">
<div class="container">
<a class="navbar-brand fw-bold" href="#top">Hacker Laws</a>
<button class="navbar-toggler" type="button" data-bs-toggle="collapse" data-bs-target="#navMenu" aria-controls="navMenu" aria-expanded="false" aria-label="Toggle navigation">
<span class="navbar-toggler-icon"></span>
</button>
<div class="collapse navbar-collapse" id="navMenu">
<ul class="navbar-nav me-auto">
<li class="nav-item">
<a class="nav-link" href="#"><i class="bi bi-book"></i> Effective Shell</a>
</li>
<li class="nav-item">
<a class="nav-link" href="#"><i class="bi bi-cup"></i> Sponsor</a>
</li>
<li class="nav-item">
<a class="nav-link" href="#"><i class="bi bi-brain"></i> Terminal AI</a>
</li>
</ul>
<ul class="navbar-nav ms-auto">
<li class="nav-item">
<a class="nav-link" href="#"><i class="bi bi-github"></i> GitHub</a>
</li>
</ul>
</div>
</div>
</nav>
<!-- Page Header -->
<header class="container my-4">
<h1>Hacker Laws</h1>
<p class="lead">Laws, Theories, Principles and Patterns that developers will find useful.</p>
</header>
<!-- Main Content -->
<main class="container">
<!-- Introduction Section -->
<section id="introduction" class="law-section">
<h2>Introduction</h2>
<p>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!</p>
<p><strong>Note:</strong> This repo contains an explanation of some laws, principles and patterns, but does not <em>advocate</em> 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.</p>
<!-- Social Sharing Icons -->
<div class="social-sharing">
<a href="#" title="Share on Twitter"><i class="bi bi-twitter"></i></a>
<a href="#" title="Share on Facebook"><i class="bi bi-facebook"></i></a>
<a href="#" title="Share on LinkedIn"><i class="bi bi-linkedin"></i></a>
</div>
<!-- Back to Top Options (choose one) -->
<div class="back-to-top mt-2">
<a href="#top">↑ Top</a>
<!-- Alternative options:
<a href="#top">Back to Top</a>
<a href="#top">Return to Top</a>
<a href="#top">Go Up</a>
<a href="#top">Scroll Up</a>
-->
</div>
</section>
<!-- 90–9–1 Principle (1% Rule) Section -->
<section id="9091-principle" class="law-section">
<h2>90–9–1 Principle (1% Rule)</h2>
<p>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.</p>
<p>Real-world examples:</p>
<ul>
<li>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%.</li>
</ul>
<p>See Also: <a href="#the-pareto-principle-the-8020-rule">Pareto Principle</a></p>
<!-- Social Sharing Icons -->
<div class="social-sharing">
<a href="#" title="Share on Twitter"><i class="bi bi-twitter"></i></a>
<a href="#" title="Share on Facebook"><i class="bi bi-facebook"></i></a>
<a href="#" title="Share on LinkedIn"><i class="bi bi-linkedin"></i></a>
</div>
<!-- Back to Top Options -->
<div class="back-to-top mt-2">
<a href="#top">↑ Top</a>
</div>
</section>
<!-- 90–90 Rule Section -->
<section id="9090-rule" class="law-section">
<h2>90–90 Rule</h2>
<p>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.</p>
<p>This is a wry reinterpretation of the <a href="#the-pareto-principle-the-8020-rule">Pareto Principle</a> (or 80-20 rule) that highlights the real-world challenges of completing engineering work. This sentiment is also echoed in <a href="#hofstadters-law">Hofstadter's Law</a>.</p>
<!-- Social Sharing Icons -->
<div class="social-sharing">
<a href="#" title="Share on Twitter"><i class="bi bi-twitter"></i></a>
<a href="#" title="Share on Facebook"><i class="bi bi-facebook"></i></a>
<a href="#" title="Share on LinkedIn"><i class="bi bi-linkedin"></i></a>
</div>
<!-- Back to Top Options -->
<div class="back-to-top mt-2">
<a href="#top">↑ Top</a>
</div>
</section>
<!-- Additional law sections would follow the same structure -->
</main>
<!-- Footer -->
<footer class="container text-center my-4">
<p>© 2025 Hacker Laws</p>
</footer>
<!-- Bootstrap Bundle with Popper -->
<script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/js/bootstrap.bundle.min.js"></script>
<script>
// Optional: Smooth scrolling for in-page links
document.querySelectorAll('a[href^="#"]').forEach(anchor => {
anchor.addEventListener('click', function(e) {
e.preventDefault();
const targetElem = document.querySelector(this.getAttribute('href'));
if (targetElem) {
targetElem.scrollIntoView({ behavior: 'smooth' });
}
});
});
</script>
</body>
</html>
================================================
FILE: .github/website/backup/index3.html
================================================
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Hacker Laws</title>
<!-- Google Font for elegant serif fonts -->
<link href="https://fonts.googleapis.com/css2?family=Libre+Baskerville:wght@400;700&display=swap" rel="stylesheet">
<!-- Bootstrap CSS -->
<link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css" rel="stylesheet" />
<!-- Bootstrap Icons -->
<link href="https://cdn.jsdelivr.net/npm/bootstrap-icons@1.10.5/font/bootstrap-icons.css" rel="stylesheet" />
<style>
/* Use an elegant serif font and a clean, minimal palette */
body {
font-family: 'Libre Baskerville', Georgia, serif;
background-color: #fff;
color: #333;
padding-top: 70px; /* account for sticky navbar */
}
.container {
max-width: 800px;
}
/* Simplified Navbar */
.navbar-custom {
background-color: #fff;
border-bottom: 1px solid #e5e5e5;
}
.navbar-brand,
.nav-link {
font-weight: 700;
}
/* Centered, minimal header */
header {
text-align: center;
margin-bottom: 2rem;
}
header h1 {
font-size: 2.5rem;
margin-bottom: 0.5rem;
}
header p.lead {
font-size: 1.25rem;
color: #555;
}
/* Law section styling: simple borders instead of shadows */
.law-section {
margin-bottom: 2rem;
padding: 1.5rem;
background-color: #fff;
border-bottom: 1px solid #e5e5e5;
}
/* Social sharing icons remain the same */
.social-sharing a {
margin-right: 0.75rem;
font-size: 1.2rem;
color: #555;
text-decoration: none;
}
.social-sharing a:hover {
color: #000;
}
/* Back to top link styling */
.back-to-top a {
font-size: 0.9rem;
text-decoration: none;
color: #007bff;
}
.back-to-top a:hover {
text-decoration: underline;
}
</style>
</head>
<body id="top">
<!-- Sticky Navbar -->
<nav class="navbar navbar-expand-lg navbar-custom fixed-top">
<div class="container">
<a class="navbar-brand" href="#top">Hacker Laws</a>
<button class="navbar-toggler" type="button" data-bs-toggle="collapse" data-bs-target="#navMenu" aria-controls="navMenu" aria-expanded="false" aria-label="Toggle navigation">
<span class="navbar-toggler-icon"></span>
</button>
<div class="collapse navbar-collapse" id="navMenu">
<ul class="navbar-nav me-auto">
<li class="nav-item">
<a class="nav-link" href="#"><i class="bi bi-book"></i> Effective Shell</a>
</li>
<li class="nav-item">
<a class="nav-link" href="#"><i class="bi bi-cup"></i> Sponsor</a>
</li>
<li class="nav-item">
<a class="nav-link" href="#"><i class="bi bi-brain"></i> Terminal AI</a>
</li>
</ul>
<ul class="navbar-nav ms-auto">
<li class="nav-item">
<a class="nav-link" href="#"><i class="bi bi-github"></i> GitHub</a>
</li>
</ul>
</div>
</div>
</nav>
<!-- Page Header -->
<header class="container my-4">
<h1>Hacker Laws</h1>
<p class="lead">Laws, Theories, Principles and Patterns that developers will find useful.</p>
</header>
<!-- Main Content -->
<main class="container">
<!-- Introduction Section -->
<section id="introduction" class="law-section">
<h2>Introduction</h2>
<p>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!</p>
<p><strong>Note:</strong> This repo contains an explanation of some laws, principles and patterns, but does not <em>advocate</em> 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.</p>
<!-- Social Sharing Icons -->
<div class="social-sharing">
<a href="#" title="Share on Twitter"><i class="bi bi-twitter"></i></a>
<a href="#" title="Share on Facebook"><i class="bi bi-facebook"></i></a>
<a href="#" title="Share on LinkedIn"><i class="bi bi-linkedin"></i></a>
</div>
<!-- Back to Top -->
<div class="back-to-top mt-2">
<a href="#top">↑ Top</a>
</div>
</section>
<!-- 90–9–1 Principle (1% Rule) Section -->
<section id="9091-principle" class="law-section">
<h2>90–9–1 Principle (1% Rule)</h2>
<p>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.</p>
<p>Real-world examples:</p>
<ul>
<li>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%.</li>
</ul>
<p>See Also: <a href="#the-pareto-principle-the-8020-rule">Pareto Principle</a></p>
<!-- Social Sharing Icons -->
<div class="social-sharing">
<a href="#" title="Share on Twitter"><i class="bi bi-twitter"></i></a>
<a href="#" title="Share on Facebook"><i class="bi bi-facebook"></i></a>
<a href="#" title="Share on LinkedIn"><i class="bi bi-linkedin"></i></a>
</div>
<!-- Back to Top -->
<div class="back-to-top mt-2">
<a href="#top">↑ Top</a>
</div>
</section>
<!-- 90–90 Rule Section -->
<section id="9090-rule" class="law-section">
<h2>90–90 Rule</h2>
<p>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.</p>
<p>This is a wry reinterpretation of the <a href="#the-pareto-principle-the-8020-rule">Pareto Principle</a> (or 80-20 rule) that highlights the real-world challenges of completing engineering work. This sentiment is also echoed in <a href="#hofstadters-law">Hofstadter's Law</a>.</p>
<!-- Social Sharing Icons -->
<div class="social-sharing">
<a href="#" title="Share on Twitter"><i class="bi bi-twitter"></i></a>
<a href="#" title="Share on Facebook"><i class="bi bi-facebook"></i></a>
<a href="#" title="Share on LinkedIn"><i class="bi bi-linkedin"></i></a>
</div>
<!-- Back to Top -->
<div class="back-to-top mt-2">
<a href="#top">↑ Top</a>
</div>
</section>
</main>
<!-- Footer -->
<footer class="container text-center my-4">
<p>© 2025 Hacker Laws</p>
</footer>
<!-- Bootstrap Bundle with Popper -->
<script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/js/bootstrap.bundle.min.js"></script>
<script>
// Smooth scrolling for in-page links
document.querySelectorAll('a[href^="#"]').forEach(anchor => {
anchor.addEventListener('click', function(e) {
e.preventDefault();
const targetElem = document.querySelector(this.getAttribute('href'));
if (targetElem) {
targetElem.scrollIntoView({ behavior: 'smooth' });
}
});
});
</script>
</body>
</html>
================================================
FILE: .github/website/backup/index4.html
================================================
================================================
FILE: .github/website/generate.py
================================================
"""Generate the Hacker Laws website from the Hacker Laws README"""
import argparse
import os
import shutil
from jinja2 import Environment, FileSystemLoader
import markdown
from bs4 import BeautifulSoup
def bisect_text(content: str, bisect_line: str) -> tuple[str, str]:
lines = content.splitlines()
head = []
tail = []
found = False
for line in lines:
if found is False and line == bisect_line:
found = True
continue
if found:
tail.append(line)
else:
head.append(line)
return ("\n".join(head), "\n".join(tail))
def load_template():
"""Load Jinja2 template from the specified directory."""
env = Environment(loader=FileSystemLoader(TEMPLATE_DIR))
return env.get_template(TEMPLATE_FILE)
def prepare_markdown(path: str) -> str:
"""
Pre-process the README markdown by removing content we will not show in
the final website.
"""
# Load the markdown content.
with open(path, "r", encoding="utf-8") as f:
content = f.read()
return content
def parse_markdown(markdown_content: str):
(_, remains) = bisect_text(markdown_content, "---")
(links, remains) = bisect_text(remains, "---")
(_, content) = bisect_text(remains, "<!-- vim-markdown-toc -->")
md = markdown.Markdown(extensions=['toc'])
links = md.convert(links)
print(f"links: {links}")
md.convert(content)
toc = md.toc
markdown_sections = content.split("\n#") # Split by Markdown headings
sections = []
laws = []
for markdown_section in markdown_sections:
if markdown_section.strip():
lines = markdown_section.split("\n", 1)
title = lines[0].strip("# ").strip()
content = md.convert(lines[1] if len(lines) > 1 else "")
full_content = md.convert(markdown_section)
id = title.lower().replace(" ", "-")
laws.append({"title": title, "content": content, "id": id})
sections.append({
"title": title,
"content": content,
"id": id,
"full_content": full_content
})
return (links, toc, sections)
def extract_static_files(html_content, output_dir):
"""
Extract linked CSS, JS, and image files and copy them to the output
directory.
"""
soup = BeautifulSoup(html_content, "html.parser")
files_to_copy = []
# Extract <link> stylesheets
for link in soup.find_all("link", href=True):
href = link["href"]
if not href.startswith(("http", "//")): # Ignore external links
files_to_copy.append(href)
# Extract <script> files
for script in soup.find_all("script", src=True):
src = script["src"]
if not src.startswith(("http", "//")):
files_to_copy.append(src)
# Extract <img> files
for img in soup.find_all("img", src=True):
src = img["src"]
if not src.startswith(("http", "//")):
files_to_copy.append(src)
# Copy files to the output directory
for file_path in files_to_copy:
src_path = os.path.join(TEMPLATE_DIR, file_path)
dest_path = os.path.join(output_dir, file_path)
if os.path.exists(src_path): # Ensure file exists before copying
os.makedirs(os.path.dirname(dest_path), exist_ok=True)
shutil.copy2(src_path, dest_path)
print(f"📂 Copied: {src_path} → {dest_path}")
else:
print(f"⚠️ Warning: Missing file {src_path} (skipping)")
return files_to_copy
def generate_site(markdown_content: str, output_dir: str):
"""Generate the static HTML file from Markdown and Jinja2 template."""
template = load_template()
(links, toc, sections) = parse_markdown(markdown_content)
# Ensure output directory exists
os.makedirs(output_dir, exist_ok=True)
# Render HTML
html_output = template.render(links=links, toc=toc, sections=sections)
# Save HTML to output directory
output_file = os.path.join(output_dir, "index.html")
with open(output_file, "w", encoding="utf-8") as f:
f.write(html_output)
print(f"✅ Static site generated: {output_file}")
# Copy static files (CSS, JS, images)
extract_static_files(html_output, output_dir)
if __name__ == "__main__":
parser = argparse.ArgumentParser(description="Generate a static site from Markdown.")
parser.add_argument("-o", "--output-dir", default="build", help="Directory to save the generated site.")
args = parser.parse_args()
# Read environment variables with defaults
TEMPLATE_FILE = os.getenv("TEMPLATE_FILE", "template.html")
TEMPLATE_DIR = os.getenv("TEMPLATE_DIR", ".")
template_path = f"{TEMPLATE_DIR}/{TEMPLATE_FILE}"
markdown_path = os.getenv("MARKDOWN_FILE", "laws.md")
output_dir = args.output_dir
print(f"📝 Loading template from: {template_path}")
print(f"📖 Loading markdown from: {markdown_path}")
print(f"💾 Outputting files to: {output_dir}")
# First, extract that markdown that we want to process.
markdown_content = prepare_markdown(markdown_path)
# Generate the site from the markdown.
generate_site(markdown_content, args.output_dir)
================================================
FILE: .github/website/makefile
================================================
SHELL := /bin/bash
TEMPLATE_DIR=src
TEMPLATE_FILE=index.html.jinja
MARKDOWN_FILE=../../README.md
OUTPUT_FILE=build/index.html
default: help
.PHONY: help
help: # Show help for each of the Makefile recipes.
@grep -E '^[a-zA-Z0-9 -]+:.*#' Makefile | sort | while read -r l; do printf "\033[1;32m$$(echo $$l | cut -f 1 -d':')\033[00m:$$(echo $$l | cut -f 2- -d'#')\n"; done
.PHONY: install
install: # 📦 install dependencies
@echo "📦 Installing dependencies..."
pip install -r requirements.txt
.PHONY: build
build: #🔨 building static site
@echo "🔨 Building static site..."
cp -rf ../../images ./build
TEMPLATE_FILE=$(TEMPLATE_FILE) MARKDOWN_FILE=$(MARKDOWN_FILE) OUTPUT_FILE=$(OUTPUT_FILE) TEMPLATE_DIR=$(TEMPLATE_DIR) \
python generate.py
.PHONY: serve
serve: # 🚀 start local server
@echo "🚀 Starting local server at http://localhost:8000..."
python3 -m http.server 8000
.PHONY: watch
watch: build # 👀 Watch for changes...
@echo "👀 Watching for changes..."
watchmedo shell-command --patterns="$(MARKDOWN_FILE);*.py;src/*" --command="make build" .
.PHONY: clean
clean: #🧹 Clean up generated files
@echo "🧹 Cleaning up generated files..."
rm -f $(OUTPUT)
================================================
FILE: .github/website/requirements.txt
================================================
markdown
jinja2
watchdog
beautifulsoup4
================================================
FILE: .github/website/src/index.html.jinja
================================================
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Hacker Laws</title>
<!-- Google tag (gtag.js) -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-RGJ5TDHWY9"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'G-RGJ5TDHWY9');
</script>
<link rel="icon" href="favicon.svg" type="image/svg+xml">
<!-- Google Fonts -->
<link href="https://fonts.googleapis.com/css2?family=Libre+Baskerville:wght@400;700&family=Inter:wght@400;600&display=swap" rel="stylesheet">
<!-- Bootstrap CSS -->
<link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css" rel="stylesheet" />
<!-- Bootstrap Icons -->
<link href="https://cdn.jsdelivr.net/npm/bootstrap-icons@1.10.5/font/bootstrap-icons.css" rel="stylesheet" />
<link rel="stylesheet" href="styles.css">
</head>
<body id="top">
<nav class="navbar navbar-expand-lg fixed-top bg-dark" data-bs-theme="dark">
<div class="container">
<a class="navbar-brand" href="#top">Hacker Laws</a>
<button class="navbar-toggler" type="button" data-bs-toggle="collapse" data-bs-target="#navMenu">
<span class="navbar-toggler-icon"></span>
</button>
<div class="collapse navbar-collapse justify-content-end" id="navMenu">
<ul class="navbar-nav me-auto">
<li class="nav-item"><a class="nav-link" href="https://effective-shell.com" target="_blank"><i class="bi bi-book"></i> Effective Shell</a></li>
<li class="nav-item"><a class="nav-link" href="https://github.com/dwmkerr/terminal-ai" target="_blank"><i class="bi bi-terminal"></i> Terminal AI</a></li>
<li class="nav-item"><a class="nav-link" href="https://github.com/sponsors/dwmkerr" target="_blank"><i class="bi bi-cup-hot"></i> Sponsor</a></li>
</ul>
<a href="https://github.com/dwmkerr/hacker-laws" target="_blank"><button class="btn btn-outline-light" type="submit"><i class="bi bi-github"></i> GitHub</button></a>
</div>
</div>
</nav>
<header class="container">
<h1>Hacker Laws</h1>
<p class="lead">Laws, Theories, Principles and Patterns that developers will find useful.</p>
</header>
<main class="container">
<!-- Quick links. -->
{{ links }}
<hr>
<!-- The table of contents. -->
{{ toc }}
<hr>
<!-- Each of the sections - most of which are laws. -->
{% for section in sections %}
<section id="{{ section.id }}" class="law-section">
{{ section.full_content | safe }}
<div class="social-sharing">
<a href="https://twitter.com/intent/tweet?url=https://hacker-laws.com/#{{ section.id}}?hashtags=example" title="Share on Twitter" target="_blank"><i class="bi bi-twitter"></i></a>
<a href="https://www.facebook.com/sharer/sharer.php?u=https://hacker-laws.com/#{{ section.id }}" title="Share on Facebook" target="_blank"><i class="bi bi-facebook"></i></a>
</div>
</section>
{% endfor %}
</main>
<footer class="container text-center my-4">
<p>© 2025 Hacker Laws</p>
</footer>
<script src="https://code.jquery.com/jquery-3.6.0.min.js"></script>
<script src="script.js"></script>
</body>
</html>
================================================
FILE: .github/website/src/script.js
================================================
$(document).ready(function() {
$("h1, h2, h3, h4, h5, h6").each(function() {
var $heading = $(this);
var headingId = $heading.attr("id") || $heading.text().trim().toLowerCase().replace(/\s+/g, "-");
// Ensure a unique ID
$heading.attr("id", headingId);
// Create the anchor link
var $anchor = $('<a>')
.attr("href", "#" + headingId)
.addClass("header-link")
.html("#");
// Append to the heading
$heading.append($anchor);
});
// Bootstrap requires that blockquote elements have the 'blockquote' class.
$('blockquote').addClass('blockquote').addClass('.quote');
});
================================================
FILE: .github/website/src/styles.css
================================================
html {
scroll-behavior: auto !important;
}
body {
font-family: 'Inter', sans-serif;
background-color: #fff;
color: #333;
padding-top: 70px;
}
.container {
max-width: 800px;
}
header {
text-align: center;
margin-bottom: 2rem;
padding: 2rem 0;
border-bottom: 1px solid #e5e5e5;
}
h1, h2, h3, h4, h5, h6 {
font-family: 'Libre Baskerville', serif;
/* Avoid scrolling under the sticky header. */
scroll-margin-top: 80px;
}
blockquote {
font-style: italic;
}
.law-section {
margin-bottom: 2rem;
padding: 1.5rem;
background-color: #fff;
border-bottom: 1px solid #e5e5e5;
position: relative;
}
.law-section h2 {
position: relative;
display: flex;
align-items: center;
}
.law-section h2 a.anchor {
text-decoration: none;
color: #999;
margin-left: 0.5rem;
visibility: hidden;
}
.law-section:hover h2 a.anchor {
visibility: visible;
}
.social-sharing a {
margin-right: 0.75rem;
font-size: 1.2rem;
color: #555;
text-decoration: none;
}
.social-sharing a:hover {
color: #000;
}
.back-to-top {
margin-top: 1rem;
}
/* Initially hide the hash link */
.header-link {
text-decoration: none;
margin-left: 12px; /* Increased left padding */
opacity: 0;
transition: opacity 0.2s;
font-size: inherit; /* Matches the heading size */
}
/* Only show the hash when the whole section is hovered */
section:hover .header-link,
article:hover .header-link,
div:hover .header-link {
opacity: 1;
}
================================================
FILE: .github/workflows/cicd.yaml
================================================
name: CI/CD
on:
push:
branches: [main]
pull_request:
workflow_dispatch:
# Permissions to check contents and open PR (release pleases) and update pages.
permissions:
contents: write
pull-requests: write
pages: write
id-token: write
jobs:
test-website-build:
runs-on: ubuntu-24.04
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Test Website Build
run: |
cd .github/website
make install
make build
cp -r build/. '../pages'
ls -al "../pages"
release:
needs: test-website-build
runs-on: ubuntu-24.04
outputs:
released: ${{ steps.release-please.outputs.release_created }}
tag: ${{ steps.release-please.outputs.tag_name }}
steps:
- uses: googleapis/release-please-action@v4
id: release-please
with:
manifest-file: .github/release-please-manifest.json
config-file: .github/release-please-config.json
release-pdf:
runs-on: ubuntu-24.04
needs: release
if: ${{ needs.release.outputs.released }}
steps:
- name: Checkout
uses: actions/checkout@v4
# Set a descriptive version. For PRs it'll be the short sha.
- name: Check Version
run: echo "${VERSION}"
env:
VERSION: ${{ needs.release.outputs.tag }}
# Set a descriptive version. For PRs it'll be the short sha.
- name: Prepare Markdown
run: |
# Set the env vars we use (version set for clarity).
export DATE=$(date +%F)
export VERSION="${VERSION}"
make -f .github/makefile prepare-markdown
env:
VERSION: ${{ needs.release.outputs.tag }}
# Create the PDF files.
- name: Create PDF
run: make -f .github/makefile create-pdf
# Publish the PDF and intermediate markdown as an artifact.
# - name: Publish PDF Artifact
# uses: actions/upload-artifact@3
# with:
# name: hacker-laws.pdf
# path: hacker-laws.pdf
- name: Attach assets to GitHub Release
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
gh release upload "${{ needs.release.outputs.tag }}" --clobber hacker-laws.pdf hacker-laws.md
deploy:
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
runs-on: ubuntu-24.04
needs: release
if: ${{ needs.release.outputs.released }}
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup Pages
uses: actions/configure-pages@v5
- name: Build Website
run: |
cd .github/website
make install
make build
cp -r build/. '../pages'
ls -al "../pages"
- name: Upload artifact
uses: actions/upload-pages-artifact@v3
with:
path: './.github/pages'
- name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v4
================================================
FILE: .gitignore
================================================
.DS_Store
================================================
FILE: LICENSE
================================================
Copyright (c) Dave Kerr 2021
# Attribution-ShareAlike 4.0 International
Creative Commons Corporation (“Creative Commons”) is not a law firm and does not provide legal services or legal advice. Distribution of Creative Commons public licenses does not create a lawyer-client or other relationship. Creative Commons makes its licenses and related information available on an “as-is” basis. Creative Commons gives no warranties regarding its licenses, any material licensed under their terms and conditions, or any related information. Creative Commons disclaims all liability for damages resulting from their use to the fullest extent possible.
### Using Creative Commons Public Licenses
Creative Commons public licenses provide a standard set of terms and conditions that creators and other rights holders may use to share original works of authorship and other material subject to copyright and certain other rights specified in the public license below. The following considerations are for informational purposes only, are not exhaustive, and do not form part of our licenses.
* __Considerations for licensors:__ Our public licenses are intended for use by those authorized to give the public permission to use material in ways otherwise restricted by copyright and certain other rights. Our licenses are irrevocable. Licensors should read and understand the terms and conditions of the license they choose before applying it. Licensors should also secure all rights necessary before applying our licenses so that the public can reuse the material as expected. Licensors should clearly mark any material not subject to the license. This includes other CC-licensed material, or material used under an exception or limitation to copyright. [More considerations for licensors](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensors).
* __Considerations for the public:__ By using one of our public licenses, a licensor grants the public permission to use the licensed material under specified terms and conditions. If the licensor’s permission is not necessary for any reason–for example, because of any applicable exception or limitation to copyright–then that use is not regulated by the license. Our licenses grant only permissions under copyright and certain other rights that a licensor has authority to grant. Use of the licensed material may still be restricted for other reasons, including because others have copyright or other rights in the material. A licensor may make special requests, such as asking that all changes be marked or described. Although not required by our licenses, you are encouraged to respect those requests where reasonable. [More considerations for the public](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensees).
## Creative Commons Attribution-ShareAlike 4.0 International Public License
By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution-ShareAlike 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions.
### Section 1 – Definitions.
a. __Adapted Material__ means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image.
b. __Adapter's License__ means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License.
c. __BY-SA Compatible License__ means a license listed at [creativecommons.org/compatiblelicenses](http://creativecommons.org/compatiblelicenses), approved by Creative Commons as essentially the equivalent of this Public License.
d. __Copyright and Similar Rights__ means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights.
e. __Effective Technological Measures__ means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements.
f. __Exceptions and Limitations__ means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material.
g. __License Elements__ means the license attributes listed in the name of a Creative Commons Public License. The License Elements of this Public License are Attribution and ShareAlike.
h. __Licensed Material__ means the artistic or literary work, database, or other material to which the Licensor applied this Public License.
i. __Licensed Rights__ means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license.
j. __Licensor__ means the individual(s) or entity(ies) granting rights under this Public License.
k. __Share__ means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them.
l. __Sui Generis Database Rights__ means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world.
m. __You__ means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning.
### Section 2 – Scope.
a. ___License grant.___
1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to:
A. reproduce and Share the Licensed Material, in whole or in part; and
B. produce, reproduce, and Share Adapted Material.
2. __Exceptions and Limitations.__ For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions.
3. __Term.__ The term of this Public License is specified in Section 6(a).
4. __Media and formats; technical modifications allowed.__ The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material.
5. __Downstream recipients.__
A. __Offer from the Licensor – Licensed Material.__ Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License.
B. __Additional offer from the Licensor – Adapted Material.__ Every recipient of Adapted Material from You automatically receives an offer from the Licensor to exercise the Licensed Rights in the Adapted Material under the conditions of the Adapter’s License You apply.
C. __No downstream restrictions.__ You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material.
6. __No endorsement.__ Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i).
b. ___Other rights.___
1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise.
2. Patent and trademark rights are not licensed under this Public License.
3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties.
### Section 3 – License Conditions.
Your exercise of the Licensed Rights is expressly made subject to the following conditions.
a. ___Attribution.___
1. If You Share the Licensed Material (including in modified form), You must:
A. retain the following if it is supplied by the Licensor with the Licensed Material:
i. identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated);
ii. a copyright notice;
iii. a notice that refers to this Public License;
iv. a notice that refers to the disclaimer of warranties;
v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable;
B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and
C. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License.
2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information.
3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable.
b. ___ShareAlike.___
In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply.
1. The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-SA Compatible License.
2. You must include the text of, or the URI or hyperlink to, the Adapter's License You apply. You may satisfy this condition in any reasonable manner based on the medium, means, and context in which You Share Adapted Material.
3. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, Adapted Material that restrict exercise of the rights granted under the Adapter's License You apply.
### Section 4 – Sui Generis Database Rights.
Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material:
a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database;
b. if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material, including for purposes of Section 3(b); and
c. You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database.
For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights.
### Section 5 – Disclaimer of Warranties and Limitation of Liability.
a. __Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You.__
b. __To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You.__
c. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability.
### Section 6 – Term and Termination.
a. This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically.
b. Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates:
1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or
2. upon express reinstatement by the Licensor.
For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License.
c. For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License.
d. Sections 1, 5, 6, 7, and 8 survive termination of this Public License.
### Section 7 – Other Terms and Conditions.
a. The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed.
b. Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License.
### Section 8 – Interpretation.
a. For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License.
b. To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions.
c. No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor.
d. Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority.
> Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the “Licensor.” The text of the Creative Commons public licenses is dedicated to the public domain under the [CC0 Public Domain Dedication](https://creativecommons.org/publicdomain/zero/1.0/legalcode). Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at [creativecommons.org/policies](http://creativecommons.org/policies), Creative Commons does not authorize the use of the trademark “Creative Commons” or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses.
>
> Creative Commons may be contacted at creativecommons.org.
================================================
FILE: README.md
================================================
<h1 align="center"><a href="https://hacker-laws.com" target="_blank">hacker-laws</a></h1>
<h4 align="center">🧠 Laws, Theories, Principles and Patterns for developers and technologists.</h4>
---
- 📖 My new book [Effective Shell (Online Version)](https://effective-shell.com) on [Amazon (Print/Kindle)](https://amzn.to/4ho0F91)
- 🌍 Try [hacker-laws.com](https://hacker-laws.com)
- 🧠 Check out my new project [Terminal AI](https://github.com/dwmkerr/terminal-ai)
- ☕️ Like this project? Consider [buying me a coffee with a one-off donation](https://github.com/sponsors/dwmkerr?frequency=one-time)
- 🎧 Listen to the podcast [The Changelog - Laws for Hackers to Live By](https://changelog.com/podcast/403)
- 📖 Download the [PDF eBook](https://github.com/dwmkerr/hacker-laws/releases/latest/download/hacker-laws.pdf)
- 🌏 See the Translations: [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇫🇷](./translations/fr.md) [🇮🇹](./translations/it-IT.md) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](./translations/tr.md) [🇮🇩](./translations/id.md) [🇯🇵](./translations/jp.md) [🇵🇱](./translations/pl.md) [🇻🇳](./translations/vi.md)
---
<!-- vim-markdown-toc GFM -->
- [Introduction](#introduction)
- [Laws](#laws)
- [90–9–1 Principle (1% Rule)](#9091-principle-1-rule)
- [90–90 Rule](#9090-rule)
- [Amdahl's Law](#amdahls-law)
- [The Broken Windows Theory](#the-broken-windows-theory)
- [Brooks' Law](#brooks-law)
- [CAP Theorem (Brewer's Theorem)](#cap-theorem-brewers-theorem)
- [Clarke's three laws](#clarkes-three-laws)
- [Conway's Law](#conways-law)
- [Cunningham's Law](#cunninghams-law)
- [Dunbar's Number](#dunbars-number)
- [The Dunning-Kruger Effect](#the-dunning-kruger-effect)
- [Fitts' Law](#fitts-law)
- [Gall's Law](#galls-law)
- [Goodhart's Law](#goodharts-law)
- [Hanlon's Razor](#hanlons-razor)
- [Hick's Law (Hick-Hyman Law)](#hicks-law-hick-hyman-law)
- [Hofstadter's Law](#hofstadters-law)
- [Hutber's Law](#hutbers-law)
- [The Hype Cycle & Amara's Law](#the-hype-cycle--amaras-law)
- [Hyrum's Law (The Law of Implicit Interfaces)](#hyrums-law-the-law-of-implicit-interfaces)
- [Jevons' Paradox](#jevons-paradox)
- [Input-Process-Output (IPO)](#input-process-output-ipo)
- [Kernighan's Law](#kernighans-law)
- [Koomey's Law](#koomeys-law)
- [Linus's Law](#linuss-law)
- [Metcalfe's Law](#metcalfes-law)
- [Moore's Law](#moores-law)
- [Murphy's Law / Sod's Law](#murphys-law--sods-law)
- [Occam's Razor](#occams-razor)
- [Parkinson's Law](#parkinsons-law)
- [Premature Optimization Effect](#premature-optimization-effect)
- [Putt's Law](#putts-law)
- [Reed's Law](#reeds-law)
- [The Bitter Lesson](#the-bitter-lesson)
- [The Ringelmann Effect](#the-ringelmann-effect)
- [The Law of Conservation of Complexity (Tesler's Law)](#the-law-of-conservation-of-complexity-teslers-law)
- [The Law of Demeter](#the-law-of-demeter)
- [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
- [The Law of the Instrument](#the-law-of-the-instrument)
- [The Law of Triviality](#the-law-of-triviality)
- [The Unix Philosophy](#the-unix-philosophy)
- [The Scout Rule](#the-scout-rule)
- [The Spotify Model](#the-spotify-model)
- [The Two Pizza Rule](#the-two-pizza-rule)
- [Twyman's law](#twymans-law)
- [Wadler's Law](#wadlers-law)
- [Wheaton's Law](#wheatons-law)
- [Principles](#principles)
- [All Models Are Wrong (George Box's Law)](#all-models-are-wrong-george-boxs-law)
- [Chesterton's Fence](#chestertons-fence)
- [Kerckhoffs's principle](#kerckhoffss-principle)
- [The Dead Sea Effect](#the-dead-sea-effect)
- [The Dilbert Principle](#the-dilbert-principle)
- [The Pareto Principle (The 80/20 Rule)](#the-pareto-principle-the-8020-rule)
- [The Shirky Principle](#the-shirky-principle)
- [The Stochastic Parrot](#the-stochastic-parrot)
- [The Peter Principle](#the-peter-principle)
- [The Robustness Principle (Postel's Law)](#the-robustness-principle-postels-law)
- [SOLID](#solid)
- [The Single Responsibility Principle](#the-single-responsibility-principle)
- [The Open/Closed Principle](#the-openclosed-principle)
- [The Liskov Substitution Principle](#the-liskov-substitution-principle)
- [The Interface Segregation Principle](#the-interface-segregation-principle)
- [The Dependency Inversion Principle](#the-dependency-inversion-principle)
- [The DRY Principle](#the-dry-principle)
- [The KISS principle](#the-kiss-principle)
- [YAGNI](#yagni)
- [The Fallacies of Distributed Computing](#the-fallacies-of-distributed-computing)
- [The Principle of Least Astonishment](#the-principle-of-least-astonishment)
- [Reading List](#reading-list)
- [Online Resources](#online-resources)
- [PDF eBook](#pdf-ebook)
- [Podcast](#podcast)
- [Contributors](#contributors)
<!-- vim-markdown-toc -->
## 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!
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](https://en.wikipedia.org/wiki/1%25_rule_(Internet_culture))
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](https://www.jmir.org/2014/2/e33/))
See Also:
- [Pareto principle](#the-pareto-principle-the-8020-rule)
### 90–90 Rule
[90-90 Rule on Wikipedia](https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule)
> 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 Principe (or 80-20 rule)](#the-pareto-principle-the-8020-rule) that highlights the real-world challenges of completing engineering work. This sentiment is also echoed in [Hofstadter's Law](#hofstadters-law).
See also:
- [Hofstadter's Law](#hofstadters-law)
- [The Pareto Principe](#the-pareto-principle-the-8020-rule)
### Amdahl's Law
[Amdahl's Law on Wikipedia](https://en.wikipedia.org/wiki/Amdahl%27s_law)
> 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:
<img width="480px" alt="Diagram: Amdahl's Law" src="./images/amdahls_law.png" />
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](#moores-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](#brooks-law)
- [Moore's Law](#moores-law)
### The Broken Windows Theory
[The Broken Windows Theory on Wikipedia](https://en.wikipedia.org/wiki/Broken_windows_theory)
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](#TODO)) 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](#TODO)
Examples:
- [The Pragmatic Programming: Software Entropy](https://flylib.com/books/en/1.315.1.15/1/)
- [Coding Horror: The Broken Window Theory](https://blog.codinghorror.com/the-broken-window-theory/)
- [OpenSource: Joy of Programming - The Broken Window Theory](https://opensourceforu.com/2011/05/joy-of-programming-broken-window-theory/)
### Brooks' Law
[Brooks' Law on Wikipedia](https://en.wikipedia.org/wiki/Brooks%27s_law)
> 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](#reading-list)'.
See also:
- [Death March](#todo)
- [Reading List: The Mythical Man Month](#reading-list)
### 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](#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_](#TODO), which has a different definition of consistency. More recently, [PACELC](#TODO) 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:
- [Inside Google Cloud Spanner and the CAP Theorem](https://cloud.google.com/blog/products/gcp/inside-cloud-spanner-and-the-cap-theorem) - Goes into the details of how Cloud Spanner works, which appears at first to seem like a platform which has _all_ of the guarantees of CAP, but under the hood is essentially a CP system.
See also:
- [ACID](#TODO)
- [The Fallacies of Distributed Computing](#the-fallacies-of-distributed-computing)
- [PACELC](#TODO)
### Clarke's three laws
[Clarke's three laws on Wikipedia](https://en.wikipedia.org/wiki/Clarke's_three_laws)
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](https://en.wikipedia.org/wiki/Conway%27s_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 oriented around features or services, the software systems will also reflect this.
See also:
- [The Spotify Model](#the-spotify-model)
### Cunningham's Law
[Cunningham's Law on Wikipedia](https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham's_Law)
> 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:
- [XKCD 386: "Duty Calls"](https://xkcd.com/386/)
### Dunbar's Number
[Dunbar's Number on Wikipedia](https://en.wikipedia.org/wiki/Dunbar%27s_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 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:
- [Conway's Law](#conways-law)
### The Dunning-Kruger Effect
[The Dunning-Kruger Effect on Wikipedia](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect)
> 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](https://en.wikipedia.org/wiki/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](https://en.wikipedia.org/wiki/Illusory_superiority).
Real-world examples:
### Fitts' Law
[Fitts' Law on Wikipedia](https://en.wikipedia.org/wiki/Fitts%27s_law)
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.
<img width="300px" alt="Diagram: Fitts Law" src="./images/Fitts_Law.svg" />
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.semanticscholar.org/paper/The-information-capacity-of-the-human-motor-system-Fitts/634c9fde5f1c411e4487658ac738dcf18d98ea8d)
### Gall's Law
[Gall's Law on Wikipedia](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law)
> A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
>
> ([John Gall](https://en.wikipedia.org/wiki/John_Gall_(author)))
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 its 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)](#the-kiss-principle)
### Goodhart's Law
[The Goodhart's Law on Wikipedia](https://en.wikipedia.org/wiki/Goodhart's_law)
> Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.
>
> _Charles Goodhart_
Also commonly referenced as:
> When a measure becomes a target, it ceases to be a good measure.
>
> _Marilyn Strathern_
The law states that the measure-driven optimizations could lead to devaluation of the measurement outcome itself. Overly selective set of measures ([KPIs](https://en.wikipedia.org/wiki/Performance_indicator)) 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.
Real-world examples:
- Assert-free tests satisfy the code coverage expectation, despite the fact that 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 Behaviour](https://coffeeandjunk.com/goodharts-campbells-law/)
- [Dilbert on bug-free software](https://dilbert.com/strip/1995-11-13)
### Hanlon's Razor
[Hanlon's Razor on Wikipedia](https://en.wikipedia.org/wiki/Hanlon%27s_razor)
> 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.
### Hick's Law (Hick-Hyman Law)
[Hick's law on Wikipedia](https://en.wikipedia.org/wiki/Hick%27s_law)
> Decision time grows logarithmically with the number of options you can choose from.
>
> William Edmund Hick and Ray Hyman
In the equation below, `T` is the time to make a decision, `n` is the number of options, and `b` is a constant which is determined by analysis of the data.
This law only applies when the number of options is _ordered_, for example, alphabetically. This is implied in the base two logarithm - which implies the decision maker is essentially performing a _binary search_. If the options are not well ordered, experiments show the time taken is linear.
This is has significant impact in UI design; ensuring that users can easily search through options leads to faster decision making.
A correlation has also been shown in Hick's Law between IQ and reaction time as shown in [Speed of Information Processing: Developmental Change and Links to Intelligence](https://www.sciencedirect.com/science/article/pii/S0022440599000369).
See also:
- [Fitts's Law](#fitts-law)
### Hofstadter's Law
[Hofstadter's Law on Wikipedia](https://en.wikipedia.org/wiki/Hofstadter%27s_law)
> 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 accurately estimating how long something will take to deliver.
This is from the book '[Gödel, Escher, Bach: An Eternal Golden Braid](#reading-list)'.
See also:
- [Reading List: Gödel, Escher, Bach: An Eternal Golden Braid](#reading-list)
### Hutber's Law
[Hutber's Law on Wikipedia](https://en.wikipedia.org/wiki/Hutber%27s_law)
> Improvement means deterioration.
>
> ([Patrick Hutber](https://en.wikipedia.org/wiki/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 Hype Cycle & Amara's Law
[The Hype Cycle on Wikipedia](https://en.wikipedia.org/wiki/Hype_cycle)
> 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 realised. 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)
[Hyrum's Law Online](http://www.hyrumslaw.com/)
> With a sufficient number of users of an API,
> it does not matter what you promise in the contract:
> all observable behaviours of your system
> will be depended on by somebody.
>
> (Hyrum Wright)
See also:
- [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
- [XKCD 1172](https://xkcd.com/1172/)
### Jevons' Paradox
[Jevons' Paradox on Wikipedia](https://en.wikipedia.org/wiki/Jevons_paradox)
> It is wholly a confusion of ideas to suppose that the economical use of fuel is equivalent to a diminished consumption. The very contrary is the truth.
>
> _William Stanley Jevons (1865)_
Named after economist William Stanley Jevons, who observed in 1865 that improvements in coal-burning engine efficiency led to *increased* coal consumption, not decreased. More efficient engines made coal economically attractive for more applications, driving overall demand higher.
In software and technology:
- Faster CPUs enable more resource-intensive software
- Better compression algorithms lead to larger files being shipped
- Faster networks result in heavier web pages
The paradox suggests efficiency gains don't reduce resource usage, but in fact can lead in time to increased consumption. [Wirth's Law](https://en.wikipedia.org/wiki/Wirth%27s_law) and [Andy and Bill's Law](https://en.wikipedia.org/wiki/Andy_and_Bill%27s_law) are also examples of Jevon's Paradox applied to computing.
See also:
- [Moore's Law](#moores-law)
- [Koomey's Law](#koomeys-law)
### Input-Process-Output (IPO)
[Input–Process–Output on Wikipedia](https://en.wikipedia.org/wiki/IPO_model)
Systems can be incredibly complex, but can typically be broken down into smaller parts that follow a simple pattern:
1. Input is provided
2. Some kind of processing or transformation is performed
3. Output is returned
A sort function in a programming language or system could be a classic example of the IPO pattern; where arbitrary input is sorted based on a predicate and returned back. A web server could be modelled as an IPO system, where HTTP requests are transformed into HTTP responses. A highly complex Generative AI system could likewise be modelled in this way, with user input being passed through a complex model and a response being generated.
The IPO pattern is present in different forms across almost all technological domains, from [functional programming](https://en.wikipedia.org/wiki/Functional_programming) languages that explicitly follow IPO patterns to [The Unix Philosophy](#the-unix-philosophy), which suggests that highly complex systems can be built by chaining together many simple IPO programs.
See also:
- [The Unix Philosophy](#the-unix-philosophy)
### Kernighan's Law
> Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
>
> (Brian Kernighan)
Kernighan's Law is named for [Brian Kernighan](https://en.wikipedia.org/wiki/Brian_Kernighan) and derived from a quote from Kernighan and Plauger's book [The Elements of Programming Style](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style):
> Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?
While hyperbolic, Kernighan's Law makes the argument that simple code is to be preferred over complex code, because debugging any issues that arise in complex code may be costly or even infeasible.
See also:
- [The KISS Principle](#the-kiss-principle)
- [The Unix Philosophy](#the-unix-philosophy)
- [Occam's Razor](#occams-razor)
### Koomey's Law
[Koomey's Law on Wikipedia](https://en.wikipedia.org/wiki/Koomey%27s_law)
> ...at a fixed computing load, the amount of battery you need will fall by a factor of two every year and a half.
>
> (Jonathan Koomey)
In 2010 Professor Jonathan Koomey discovered that the trend in number of computations per joule of energy dissipated had been remarkably stable. This trend became known as Koomey's Law - that the amount of battery needed for a given computing load would half each 2.5 years.
Koomey performed a follow-up analysis in 2010 and found that this trend had slowed, similar to how [Moore's Law](#moores-law) had slowed. This seemed to be related to limitations around how small transistors can be made, as well as [Dennard Scaling](https://en.wikipedia.org/wiki/Dennard_scaling).
See also:
- [Moore's Law](#moores-law)
- [Dennard Scaling](https://en.wikipedia.org/wiki/Dennard_scaling)
### Linus's Law
[Linus's Law on Wikipedia](https://en.wikipedia.org/wiki/Linus%27s_law)
> Given enough eyeballs, all bugs are shallow.
>
> _Eric S. Raymond_
This law simply states that the more people who can see a problem, the higher the likelihood that someone will have seen and solved the problem before, or something very similar.
Although it was originally used to describe the value of open-source models for projects it can be accepted for any kind of software project. It can also be extended to processes - more code reviews, more static analysis and multi-disciplined test processes will make the problems more visible and easy to identify.
A more formal statement can be:
> Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and can be solved by someone who has encountered a similar problem before.
This law was named in honour of [Linus Torvalds](https://en.wikipedia.org/wiki/Linus_Torvalds) in Eric S. Raymond's book "[The Cathedral and the Bazaar](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar)".
### Metcalfe's Law
[Metcalfe's Law on Wikipedia](https://en.wikipedia.org/wiki/Metcalfe's_law)
> In network theory, the value of a system grows as approximately the square of the number of users of the system.
This law is based on the number of possible pairwise connections within a system and is closely related to [Reed's Law](#reeds-law). 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](#dunbars-number).
See also:
- [Reed's Law](#reeds-law)
- [Dunbar's Number](#dunbars-number)
### Moore's Law
[Moore's Law on Wikipedia](https://en.wikipedia.org/wiki/Moore%27s_law)
> The number of transistors in an integrated circuit doubles approximately every two years.
Often used to illustrate the sheer speed at which semiconductor and chip technology has improved, Moore's prediction has proven to be highly accurate over from the 1970s to the late 2000s. In more recent years, the trend has changed slightly, partly due to [physical limitations on the degree to which components can be miniaturised](https://en.wikipedia.org/wiki/Quantum_tunnelling). However, advancements in parallelisation, and potentially revolutionary changes in semiconductor technology and quantum computing may mean that Moore's Law could continue to hold true for decades to come.
See also:
- [Koomey's Law](#koomeys-law)
### Murphy's Law / Sod's Law
[Murphy's Law on Wikipedia](https://en.wikipedia.org/wiki/Murphy%27s_law)
> Anything that can go wrong will go wrong.
Related to [Edward A. Murphy, Jr](https://en.wikipedia.org/wiki/Edward_A._Murphy_Jr.) _Murphy's Law_ states that if a thing can go wrong, it will go wrong.
This is a common adage among developers. Sometimes the unexpected happens when developing, testing or even in production. This can also be related to the (more common in British English) _Sod's Law_:
> If something can go wrong, it will, at the worst possible time.
These 'laws' are generally used in a comic sense. However, phenomena such as [_Confirmation Bias_](#TODO) and [_Selection Bias_](#TODO) can lead people to perhaps over-emphasise these laws (the majority of times when things work, they go unnoticed, failures however are more noticeable and draw more discussion).
See Also:
- [Confirmation Bias](#TODO)
- [Selection Bias](#TODO)
### Occam's Razor
[Occam's Razor on Wikipedia](https://en.wikipedia.org/wiki/Occam's_razor)
> Entities should not be multiplied without necessity.
>
> William of Ockham
Occam's razor says that among several possible solutions, the most likely solution is the one with the least number of concepts and assumptions. This solution is the simplest and solves only the given problem, without introducing accidental complexity and possible negative consequences.
See also:
- [YAGNI](#yagni)
- [No Silver Bullet: Accidental Complexity and Essential Complexity](https://en.wikipedia.org/wiki/No_Silver_Bullet)
Example:
- [Lean Software Development: Eliminate Waste](https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste)
### Parkinson's Law
[Parkinson's Law on Wikipedia](https://en.wikipedia.org/wiki/Parkinson%27s_law)
> Work expands so as to fill the time available for its completion.
In its original context, this Law was based on studies of bureaucracies. It may be pessimistically applied to software development initiatives, the theory being that teams will be inefficient until deadlines near, then rush to complete work by the deadline, thus making the actual deadline somewhat arbitrary.
See also:
- [Hofstadter's Law](#hofstadters-law)
### Premature Optimization Effect
[Premature Optimization on WikiWeb](http://wiki.c2.com/?PrematureOptimization)
> Premature optimization is the root of all evil.
>
> [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en)
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](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat)
> 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 organisations, 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](#the-peter-principle) or [The Dilbert Principle](#the-dilbert-principle).
However, it should be stressed that Laws such as this are vast generalisations and may apply to _some_ types of organisations, and not apply to others.
See also:
- [The Peter Principle](#the-peter-principle)
- [The Dilbert Principle](#the-dilbert-principle)
### Reed's Law
[Reed's Law on Wikipedia](https://en.wikipedia.org/wiki/Reed's_law)
> The utility of large networks, particularly social networks, scales exponentially with the size of the network.
This law is based on graph theory, where the utility scales as the number of possible sub-groups, which is faster than the number of participants or the number of possible pairwise connections. Odlyzko and others have argued that Reed's Law overstates the utility of the system by not accounting for the limits of human cognition on network effects; see [Dunbar's Number](#dunbars-number).
See also:
- [Metcalfe's Law](#metcalfes-law)
- [Dunbar's Number](#dunbars-number)
### The Bitter Lesson
[The Bitter Lesson by Richard S. Sutton](http://www.incompleteideas.net/IncIdeas/BitterLesson.html)
> The biggest lesson that can be read from 70 years of AI research is that general methods that leverage computation are ultimately the most effective, and by a large margin.
>
> Richard S. Sutton (2019)
The "Bitter Lesson", stated by [Rich S. Sutton](https://en.wikipedia.org/wiki/Richard_S._Sutton), says that scale (in terms of both data and computational power) has driven the most significant advancements in AI research, rather than the intricacies of the research methods themselves.
He goes on to suggest that this indicates we should stop trying to build simplified (or even complex) models of the mind as history has shown that these have always in the long term been failures compared to (as an example) scaling the capacity of neural networks and applying existing methods such as convolution.
### The Ringelmann Effect
[The Ringelmann effect on Wikipedia](https://en.wikipedia.org/wiki/Ringelmann_effect)
The Ringelmann Effect is the tendency of an individual to become increasingly inefficient as more and more people are involved in a task. In other words, as more individuals are added to a team, the more the average individual performance decreases. Multiple causes are believed to be at work, including loss of motivation ("[social loafing](https://en.wikipedia.org/wiki/Social_loafing)") and challenges related to coordination.
See also:
- [Brooks' Law](#brooks-law)
### The Law of Conservation of Complexity (Tesler's Law)
[The Law of Conservation of Complexity on Wikipedia](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity)
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 Demeter
[The Law of Demeter on Wikipedia](https://en.wikipedia.org/wiki/Law_of_Demeter)
> Don't talk to strangers.
The Law of Demeter, also known as "The Principle of Least Knowledge" is a principle for software design, particularly relevant in object orientated languages.
It states that a unit of software should talk only to its immediate collaborators. An object `A` with a reference to object `B` can call its methods, but if `B` has a reference to object `C`, `A` should not call `C`s methods. So, if `C` has a `doThing()` method, `A` should not invoke it directly; `B.getC().doThis()`.
Following this principal limits the scope of changes, making them easier and safer in future.
### The Law of Leaky Abstractions
[The Law of Leaky Abstractions on Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/)
> All non-trivial abstractions, to some degree, are leaky.
>
> ([Joel Spolsky](https://twitter.com/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.
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 underlying processes, actually makes dealing with the problem at hand _more_ complex in some cases.
See also:
- [Hyrum's Law](#hyrums-law-the-law-of-implicit-interfaces)
Real-world examples:
- [Photoshop Slow Startup](https://forums.adobe.com/thread/376152) - an issue I encountered in the past. Photoshop would be slow to startup, sometimes taking minutes. It seems the issue was that on startup it reads some information about the current default printer. However, if that printer is actually a network printer, this could take an extremely long time. The _abstraction_ of a network printer being presented to the system similar to a local printer caused an issue for users in poor connectivity situations.
### The Law of the Instrument
[The Law of the Instrument](https://en.wikipedia.org/wiki/Law_of_the_instrument)
> I call it the law of the instrument, and it may be formulated as follows: Give a small boy a hammer, and he will find that everything he encounters needs pounding.
>
> _Abraham Kaplan_
> If all you have is a hammer, everything looks like a nail.
>
> _Abraham Maslow_
In the context of computer programming, this law suggests that people tend to use tools that are familiar with, rather than the best possible tool. This over-reliance on a familiar tool is an anti-pattern referred to as 'the golden hammer'.
See also:
- [Avoiding the law of the instrument](https://josemdev.com/avoiding-the-law-of-the-instrument/)
- [Anti-Pattern - The Golden Hammer](https://archive.org/details/antipatternsrefa0000unse/page/111/mode/2up)
### The Law of Triviality
[The Law of Triviality on Wikipedia](https://en.wikipedia.org/wiki/Law_of_triviality)
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. A related term is '[Yak Shaving](https://en.wiktionary.org/wiki/yak_shaving),' which connotes a seemingly irrelevant activity that is part of a long chain of prerequisites to the main task.
### The Unix Philosophy
[The Unix Philosophy on Wikipedia](https://en.wikipedia.org/wiki/Unix_philosophy)
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 of simple building blocks.
### The Scout Rule
[The Scout Rule on O'Reilly](https://www.oreilly.com/library/view/97-things-every/9780596809515/ch08.html)
> Always leave the code better than you found it.
>
> (Robert C. Martin (Uncle Bob))
Based on the "Scout Rule", which is "always leave the campground cleaner than you found it", the Scout Rule in programming is simply "always leave the code cleaner than you found it".
This was introduced in the first chapter of the book [Clean Code](https://www.goodreads.com/book/show/3735293-clean-code) by Bob Martin. The rule suggests that developers should perform 'optimistic refactoring', which means to endeavour to improve the overall quality of the code when you work on it. If you see a mistake, attempt to fix it or clean it up. However, when making changes to code which seems incorrect, it may be worth remembering [Chesterton's Fence](#chestertons-fence)!
See also:
- [Reading List: Clean Code](#reading-list)
- [Chesterton's Fence](#chestertons-fence)
- [The Broken Windows Theory](#broken-windows-theory)
https://www.amazon.sg/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
### The Spotify Model
[The Spotify Model on Spotify Labs](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/)
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.
Members of the organisation have described that the actual meaning of these groups changes, evolves and is an on-going experiment. The fact that the model is a _process in motion_, rather than a fixed model continues to lead to varying interpretations of the structure, which may be based on presentations given by employees at conferences. This means 'snapshots' may be 're-packaged' by third parties as a _fixed structure_, with the fact that the model is dynamic being lost.
### The Two Pizza Rule
> If you can't feed a team with two pizzas, it's too large.
>
> (Jeff Bezos)
This rule suggests that regardless of the size of the company, teams should be small enough to be fed by two pizzas. Attributed to Jeff Bezos and Amazon, this belief suggests that large teams are inherently inefficient. This is supported by the fact that as the team size increases linearly, the links between people increases quadratically; thus the cost of coordinating and communicating also grows quadratically. If this cost of coordination is essentially overhead, then smaller teams should be preferred.
The number of links between people can be expressed as `n(n-1)/2` where n = number of people.
<img width="200px" alt="Complete graph; Links between people" src="./images/complete_graph.png" />
### Twyman's law
[Twyman's Law on Wikipedia](https://en.wikipedia.org/wiki/Twyman%27s_law)
> The more unusual or interesting the data, the more likely they are to have been the result of an error of one kind or another.
This law suggests that when there are particularly unusual data points, it is more likely that they are the result of errors or manipulation. For example, if a dataset of long-jump results from a sporting event showed a maximum value of 20 meters (more than twice the world record), it is more likely to be due to an error (such as recording a value in feet rather than meters) than due to an unusually long jump. It is also more likely in this case that the results could have been manipulated.
See also:
- [Sagan Standard](#TODO)
### Wadler's Law
[Wadler's Law on wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law)
> In any language design, the total time spent discussing a feature in this list is proportional to two raised to the power of its position.
>
> 0. Semantics
> 1. Syntax
> 2. Lexical syntax
> 3. 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](#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 Law of Triviality](#the-law-of-triviality)
### Wheaton's Law
[The Link](http://www.wheatonslaw.com/)
[The Official Day](https://dontbeadickday.com/)
> Don't be a dick.
>
> _Wil Wheaton_
Coined by Wil Wheaton (Star Trek: The Next Generation, The Big Bang Theory), this simple, concise, and powerful law aims for an increase in harmony and respect within a professional organization. It can be applied when speaking with coworkers, performing code reviews, countering other points of view, critiquing, and in general, most professional interactions humans have with each other.
## Principles
Principles are generally more likely to be guidelines relating to design.
### All Models Are Wrong (George Box's Law)
[All Models Are Wrong](https://en.wikipedia.org/wiki/All_models_are_wrong)
> All models are wrong, but some are useful.
>
> _George Box_
This principle suggests that all models of systems are flawed, but that as long as they are not _too_ flawed they may be useful. This principle has its roots in statistics but applies to scientific and computing models as well.
A fundamental requirement of most software is to model a system of some kind. Regardless of whether the system being modeled is a computer network, a library, a graph of social connections or any other kind of system, the designer will have to decide an appropriate level of detail to model. Excessive detail may lead to too much complexity, too little detail may prevent the model from being functional.
See also:
- [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
### Chesterton's Fence
[Chesterton's Fence on Wikipedia](https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence)
> Reforms should not be made until the reasoning behind the existing state of affairs is understood.
This principle is relevant in software engineering when removing technical debt. Each line of a program was originally written by someone for some reason. Chesterton's Fence suggests that one should try to understand the context and meaning of the code fully, before changing or removing it, even if at first glance it seems redundant or incorrect.
The name of this principle comes from a story by [G.K. Chesterton](https://en.wikipedia.org/wiki/G._K._Chesterton). A man comes across a fence crossing the middle of the road. He complains to the mayor that this useless fence is getting in the way, and asks to remove it. The mayor asks why the fence is there in the first place. When the man says he doesn't know, the mayor says, "If you don't know its purpose, I certainly won't let you remove it. Go and find out the use of it, and then I may let you destroy it."
### Kerckhoffs's principle
[Kerckhoffs's principle on Wikipedia](https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle)
> "...design your system assuming that your opponents know it in detail."
>
> _Steven M. Bellovin's formulation of Kerckhoff's Principle_
This principle of cryptography was an axiom created by cryptographer Auguste Kerckhoffs. He stated that a cryptosystem should be secure, even if everything about the system, except the key, is public knowledge. Not to be confused with [_"security through obscurity"_](#todo).
The gold standard for any secret-keeping system is that implementation details should be publicly distributed, without sacrificing or compromising security of said system.
The history of cryptography has shown that open discussion and analysis of cryptographic systems leads to better and more secure systems - as researchers are able to test for and expose potential vulnerabilities.
- [Shannon's Maxim](#todo)
### The Dead Sea Effect
[The Dead Sea Effect on Bruce F. Webster](http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-dead-sea-effect/)
> "... [T]he more talented and effective IT engineers are the ones most likely to leave - to evaporate ... [those who tend to] remain behind [are] the 'residue' — the least talented and effective IT engineers."
>
> _Bruce F. Webster_
The "Dead Sea Effect" suggests that in any organisation, the skills/talent/efficacy of engineers is often inversely proportional to their time in the company.
Typically, highly skilled engineers find it easy to gain employment elsewhere and are the first to do so. Engineers who have obsolete or weak skills will tend to remain with the company, as finding employment elsewhere is difficult. This is particularly pronounced if they have gained incremental pay rises over their time in the company, as it can be challenging to get equivalent remuneration elsewhere.
### The Dilbert Principle
[The Dilbert Principle on Wikipedia](https://en.wikipedia.org/wiki/Dilbert_principle)
> 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](#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 1995 Wall Street Journal article, and expanded upon it in his 1996 business book, [The Dilbert Principle](#reading-list).
See Also:
- [The Peter Principle](#the-peter-principle)
- [Putt's Law](#putts-law)
### The Pareto Principle (The 80/20 Rule)
[The Pareto Principle on Wikipedia](https://en.wikipedia.org/wiki/Pareto_principle)
> 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:
- 80% of a certain piece of software can be written in 20% of the total allocated time (conversely, the hardest 20% of the code takes 80% of the time)
- 20% of the effort produces 80% of the result
- 20% of the work creates 80% of the revenue
- 20% of the bugs cause 80% of the crashes
- 20% of the features cause 80% of the usage
In the 1940s 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](https://en.wikipedia.org/wiki/Joseph_M._Juran).
This principle is also known as: The 80/20 Rule, The Law of the Vital Few, and The Principle of Factor Sparsity.
Real-world examples:
- In 2002 Microsoft reported that by fixing the top 20% of the most-reported bugs, 80% of the related errors and crashes in windows and office would become eliminated ([Reference](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)).
### The Shirky Principle
[The Shirky Principle explained](https://kk.org/thetechnium/the-shirky-prin/)
> Institutions will try to preserve the problem to which they are the solution.
>
> _Clay Shirky_
The Shirky Principle suggests that complex solutions - a company, an industry, or a technology - can become so focused on the problem that they are solving, that they can inadvertently perpetuate the problem itself. This may be deliberate (a company striving to find new nuances to a problem which justify continued development of a solution), or inadvertent (being unable or unwilling to accept or build a solution which solves the problem completely or obviates it).
Related to:
- Upton Sinclair's famous line, _"It is difficult to get a man to understand something, when his salary depends upon his not understanding it!"_
- Clay Christensen's _The Innovator's Dilemma_
See also:
- [Pareto Principle](#the-pareto-principle-the-8020-rule)
### The Stochastic Parrot
[On the Dangers of Stochastic Parrots - Bender, Gebru, et al. (2021)](https://dl.acm.org/doi/10.1145/3442188.3445922)
> Contrary to how it may seem when we observe its output, an LM is a system for haphazardly stitching together sequences of linguistic forms it has observed in its vast training data, according to probabilistic information about how they combine, but without any reference to meaning: a stochastic parrot.
>
> _Emily M. Bender, Timnit Gebru, et al. (2021)_
The term argues that Large Language Models (LLMs) produce statistically likely sequences of text based on training data, without genuine comprehension. Essentially - confident-sounding output is not evidence of correctness or understanding.
Models can (and do) "hallucinate" - producing plausible sounding output or confidently making statements which are demonstrably wrong. This does not devalue these models, but highlights important characteristics which must be accounted for when using them.
See also:
- [The Bitter Lesson](#the-bitter-lesson)
- [All Models Are Wrong (George Box's Law)](#all-models-are-wrong-george-boxs-law)
### The Peter Principle
[The Peter Principle on Wikipedia](https://en.wikipedia.org/wiki/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 organisation (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 initially start out in deeply technical roles, but often have a career path which leads to _managing_ other engineers - which requires a fundamentally different skill set.
See Also:
- [The Dilbert Principle](#the-dilbert-principle)
- [Putt's Law](#putts-law)
### The Robustness Principle (Postel's Law)
[The Robustness Principle on Wikipedia](https://en.wikipedia.org/wiki/Robustness_principle)
> 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 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. These implications and other issues are described by Eric Allman in [The Robustness Principle Reconsidered](https://queue.acm.org/detail.cfm?id=1999945).
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](#hyrums-law-the-law-of-implicit-interfaces)
### SOLID
This is an acronym, which refers to:
These are key principles in [Object-Oriented Programming](#todo). Design principles such as these should be able to aid developers build more maintainable systems.
### The Single Responsibility Principle
[The Single Responsibility Principle on Wikipedia](https://en.wikipedia.org/wiki/Single_responsibility_principle)
> Every module or class should have a single responsibility only.
The first of the '[SOLID](#solid)' principles. This principle suggests that modules or classes should do one thing and one thing only. In more practical terms, this means that a single, small change to a feature of a program should require a change in one component only. For example, changing how a password is validated for complexity should require a change in only one part of the program.
Theoretically, this should make the code more robust, and easier to change. Knowing that a component being changed has a single responsibility only means that _testing_ that change should be easier. Using the earlier example, changing the password complexity component should only be able to affect the features which relate to password complexity. It can be much more difficult to reason about the impact of a change to a component which has many responsibilities.
See also:
- [Object-Oriented Programming](#todo)
- [SOLID](#solid)
### The Open/Closed Principle
[The Open/Closed Principle on Wikipedia](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle)
> Entities should be open for extension and closed for modification.
The second of the '[SOLID](#solid)' principles. This principle states that entities (which could be classes, modules, functions and so on) should be able to have their behaviour _extended_, but that their _existing_ behaviour should not be able to be modified.
As a hypothetical example, imagine a module which is able to turn a Markdown document into HTML. Now imagine there is a new syntax added to the Markdown specification, which adds support for mathematical equations. The module should be _open to extension_ to implement the new mathematics syntax. However, existing syntax implementations (like paragraphs, bullets, etc) should be _closed for modification_. They already work, we don't want people to change them.
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 behaviour changed in unexpected ways.
See also:
- [Object-Oriented Programming](#todo)
- [SOLID](#solid)
### The Liskov Substitution Principle
[The Liskov Substitution Principle on Wikipedia](https://en.wikipedia.org/wiki/Liskov_substitution_principle)
> It should be possible to replace a type with a subtype, without breaking the system.
The third of the '[SOLID](#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 usable 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](#todo)
- [SOLID](#solid)
### The Interface Segregation Principle
[The Interface Segregation Principle on Wikipedia](https://en.wikipedia.org/wiki/Interface_segregation_principle)
> No client should be forced to depend on methods it does not use.
The fourth of the '[SOLID](#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](#todo) between different components. [Duck typing](#todo) is a methodology which enforces this principle by eliminating explicit interfaces.
See also:
- [Object-Oriented Programming](#todo)
- [SOLID](#solid)
- [Duck Typing](#todo)
- [Decoupling](#todo)
### The Dependency Inversion Principle
[The Dependency Inversion Principle on Wikipedia](https://en.wikipedia.org/wiki/Dependency_inversion_principle)
> High-level modules should not be dependent on low-level implementations.
The fifth of the '[SOLID](#solid)' principles. This principle states that higher-level orchestrating components should not have to know the details of their dependencies.
As an example, imagine we have a program which read metadata from a website. We would assume that the main component would have to know about a component to download the webpage content, then a component which can read the metadata. If we were to take dependency inversion into account, the main component would depend only on an abstract component which can fetch byte data, and then an abstract component which would be able to read metadata from a byte stream. The main component would not know about TCP/IP, HTTP, HTML, etc.
This principle is complex, as it can seem to 'invert' the expected dependencies of a system (hence the name). In practice, it also means that a separate orchestrating component must ensure the correct implementations of abstract types are used (e.g. in the previous example, _something_ must still provide the metadata reader component a HTTP file downloader and HTML meta tag reader). This then touches on patterns such as [Inversion of Control](#todo) and [Dependency Injection](#todo).
See also:
- [Object-Oriented Programming](#todo)
- [SOLID](#solid)
- [Inversion of Control](#todo)
- [Dependency Injection](#todo)
### The DRY Principle
[The DRY Principle on Wikipedia](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)
> 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 1999 by Andrew Hunt and Dave Thomas in the book [The Pragmatic Programmer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
> 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 Programmer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
### The KISS principle
[KISS on Wikipedia](https://en.wikipedia.org/wiki/KISS_principle)
> Keep it simple, stupid
The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided. Originating in the U.S. Navy in 1960, the phrase has been associated with aircraft engineer Kelly Johnson.
The principle is best exemplified by the story of Johnson handing a team of design engineers a handful of tools, with the challenge that the jet aircraft they were designing must be repairable by an average mechanic in the field under combat conditions with only these tools. Hence, the "stupid" refers to the relationship between the way things break and the sophistication of the tools available to repair them, not the capabilities of the engineers themselves.
See also:
- [Gall's Law](#galls-law)
### YAGNI
[YAGNI on Wikipedia](https://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it)
> Always implement things when you actually need them, never when you just foresee that you need them.
>
> ([Ron Jeffries](https://twitter.com/RonJeffries)) (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](#reading-list)
### The Fallacies of Distributed Computing
[The Fallacies of Distributed Computing on Wikipedia](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing)
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](https://en.wikipedia.org/wiki/Bill_Joy) and [Tom Lyon](https://twitter.com/aka_pugs) around 1991 and first classified by [James Gosling](https://en.wikipedia.org/wiki/James_Gosling) as the "Fallacies of Networked Computing". [L. Peter Deutsch](https://en.wikipedia.org/wiki/L._Peter_Deutsch) added the 5th, 6th and 7th fallacies. In the late 90's Gosling added the 8th fallacy.
The group was inspired by what was happening at the time inside [Sun Microsystems](https://en.wikipedia.org/wiki/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](https://medium.com/baseds/foraging-for-the-fallacies-of-distributed-computing-part-1-1b35c3b85b53)
### The Principle of Least Astonishment
[The Principle of Least Astonishment on Wikipedia](https://en.wikipedia.org/wiki/Principle_of_least_astonishment)
> People are part of the system. The design should match the user's experience, expectations, and mental models.
>
> Frans Kaashoek
This principle proposes that systems and interfaces should be designed in a way that features and functionality is easily discovered and matches users expectations. Features that 'surprise' users should be discouraged in favour of features that can be intuitively reasoned about based on existing patterns and practices.
Many examples are present in user interfaces, such as a 'pull down' gesture on a mobile appliation to refresh content. Another example would be command line tools, where many standards exist for how parameters are named, common parameters that should be available and so on.
See also:
- [Convention Over Configuration](#todo)
## Reading List
If you have found these concepts interesting, you may enjoy the following books.
- [Clean Code - Robert C. Martin](https://www.goodreads.com/book/show/3735293-clean-code) - One of the most well respected books on how to write clean, maintainable code.
- [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Covers the core principles of Extreme Programming.
- [Gödel, Escher, Bach: An Eternal Golden Braid - Douglas R. Hofstadter.](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - This book is difficult to classify. [Hofstadter's Law](#hofstadters-law) is from the book.
- [Structure and Interpretation of Computer Programs - Harold Abelson, Gerald Jay Sussman, Julie Sussman](https://www.goodreads.com/book/show/43713) - If you were a comp sci or electical engineering student at MIT or Cambridge this was your intro to programming. Widely reported as being a turning point in people's lives.
- [The Cathedral and the Bazaar - Eric S. Raymond](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar) - a collection of essays on open source. This book was the source of [Linus's Law](#linuss-law).
- [The Dilbert Principle - Scott Adams](https://www.goodreads.com/book/show/85574.The_Dilbert_Principle) - A comic look at corporate America, from the author who created the [Dilbert Principle](#the-dilbert-principle).
- [The Mythical Man Month - Frederick P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - A classic volume on software engineering. [Brooks' Law](#brooks-law) is a central theme of the book.
- [The Peter Principle - Lawrence J. Peter](https://www.goodreads.com/book/show/890728.The_Peter_Principle) - Another comic look at the challenges of larger organisations and people management, the source of [The Peter Principle](#the-peter-principle).
## Online Resources
Some useful resources and reading.
- [CB Insights: 8 Laws Driving Success In Tech: Amazon's 2-Pizza Rule, The 80/20 Principle, & More](https://www.cbinsights.com/research/report/tech-laws-success-failure) - an interesting write up of some laws which have been highly influential in technology.
## PDF eBook
The project is available as a PDF eBook, [download the latest PDF eBook with this link](https://github.com/dwmkerr/hacker-laws/releases/latest/download/hacker-laws.pdf) or check the [release](https://github.com/dwmkerr/hacker-laws/releases) page for older versions.
A new version of the eBook is created automatically when a new version tag is pushed.
## Podcast
Hacker Laws has been featured in [The Changelog](https://changelog.com/podcast/403), you can check out the Podcast episode with the link below:
<a href="https://changelog.com/podcast/403" target="_blank"><img src="./images/changelog-podcast.png" width="800px" alt="Changelog Podcast Image" /></a>
## Contributors
Thanks goes to these wonderful people ([emoji key](https://allcontributors.org/docs/en/emoji-key)):
<!-- ALL-CONTRIBUTORS-LIST:START - Do not remove or modify this section -->
<!-- prettier-ignore-start -->
<!-- markdownlint-disable -->
<table>
<tbody>
<tr>
<td align="center" valign="top" width="14.28%"><a href="https://github.com/hemmatt"><img src="https://avatars.githubusercontent.com/u/22114089?v=4?s=100" width="100px;" alt="Amir Hemmati"/><br /><sub><b>Amir Hemmati</b></sub></a><br /><a href="https://github.com/dwmkerr/hacker-laws/commits?author=hemmatt" title="Documentation">📖</a></td>
</tr>
</tbody>
</table>
<!-- markdownlint-restore -->
<!-- prettier-ignore-end -->
<!-- ALL-CONTRIBUTORS-LIST:END -->
This project follows the [all-contributors](https://github.com/all-contributors/all-contributors) specification. Contributions of any kind welcome!
================================================
FILE: assets/site/index.html
================================================
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Interactive Hacker Laws Stack</title>
<style>
body {
display: flex;
justify-content: center;
align-items: center;
height: 100vh;
background-color: #f5f5f5;
margin: 0;
font-family: Arial, sans-serif;
}
#stack {
width: 400px;
height: 500px;
overflow-y: auto;
position: relative;
border: 1px solid #ddd;
border-radius: 8px;
background-color: #fff;
box-shadow: 0 2px 10px rgba(0,0,0,0.1);
padding: 10px;
}
.law-item {
text-align: left;
padding: 4px;
transition: transform 0.2s ease, opacity 0.2s;
transform-origin: left;
font-size: 16px;
color: #333;
margin: 6px 0;
position: relative;
display: flex;
align-items: center;
}
.law-item::before {
content: '';
display: block;
width: 6px;
height: 6px;
border-radius: 50%;
background-color: #aaa;
margin-right: 8px;
transition: height 0.2s, background-color 0.2s;
}
</style>
</head>
<body>
<div id="stack" class="stack"></div>
<script>
const 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", "Hofstadter's Law", "Hutber's Law",
"The Hype Cycle & Amara's Law", "Hyrum's Law (The Law of Implicit Interfaces)",
"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", "The Dilbert Principle", "The Pareto Principle (The 80/20 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"
];
const stack = document.getElementById('stack');
const maxZoom = 1.5;
const minZoom = 0.6;
laws.forEach(title => {
const div = document.createElement('div');
div.className = 'law-item';
div.innerText = title;
stack.appendChild(div);
});
function updateScale(e) {
const items = document.querySelectorAll('.law-item');
items.forEach(item => {
const itemRect = item.getBoundingClientRect();
const itemCenter = (itemRect.top + itemRect.bottom) / 2;
const distance = Math.abs(e.clientY - itemCenter);
const scale = Math.max(maxZoom - distance / 150, minZoom);
const opacity = Math.max(1 - distance / 300, 0.3);
item.style.transform = `scale(${scale})`;
item.style.opacity = opacity;
const dot = item.querySelector('::before');
const barHeight = Math.max(6, 30 - distance / 10);
item.style.setProperty('--dot-height', barHeight + 'px');
item.style.setProperty('--dot-color', distance < 50 ? '#333' : '#aaa');
item.querySelector('::before');
item.style.setProperty('--dot-height', barHeight + 'px');
});
}
document.addEventListener('mousemove', updateScale);
// Initial positioning
updateScale({ clientY: window.innerHeight / 2 });
</script>
<style>
.law-item::before {
height: var(--dot-height, 6px);
background-color: var(--dot-color, #aaa);
}
</style>
</body>
</html>
================================================
FILE: assets/site/index2.html
================================================
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Interactive Hacker Laws Stack</title>
<style>
body {
display: flex;
justify-content: center;
align-items: center;
height: 100vh;
background-color: #f5f5f5;
margin: 0;
font-family: Arial, sans-serif;
}
#stack {
width: 400px;
height: 500px;
overflow-y: auto;
position: relative;
border: 1px solid #ddd;
border-radius: 8px;
background-color: #fff;
box-shadow: 0 2px 10px rgba(0,0,0,0.1);
padding: 10px;
}
.law-item {
text-align: left;
padding: 2px 4px;
transition: transform 0.2s ease, opacity 0.2s;
transform-origin: left;
font-size: 15px;
color: #333;
margin: 4px 0;
position: relative;
display: flex;
align-items: center;
}
.law-item::before {
content: '';
display: block;
width: var(--bar-width, 6px);
height: 6px;
border-radius: 3px;
background-color: var(--bar-color, #aaa);
margin-right: 10px;
transition: width 0.2s, background-color 0.2s;
}
</style>
</head>
<body>
<div id="stack" class="stack"></div>
<script>
const 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", "Hofstadter's Law", "Hutber's Law",
"The Hype Cycle & Amara's Law", "Hyrum's Law (The Law of Implicit Interfaces)",
"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", "The Dilbert Principle", "The Pareto Principle (The 80/20 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"
];
const stack = document.getElementById('stack');
const maxZoom = 1.8;
const minZoom = 0.5;
laws.forEach(title => {
const div = document.createElement('div');
div.className = 'law-item';
div.innerText = title;
stack.appendChild(div);
});
function updateScale(e) {
const items = document.querySelectorAll('.law-item');
items.forEach(item => {
const itemRect = item.getBoundingClientRect();
const itemCenter = (itemRect.top + itemRect.bottom) / 2;
const distance = Math.abs(e.clientY - itemCenter);
const scale = Math.max(maxZoom - distance / 120, minZoom);
const opacity = Math.max(1 - distance / 250, 0.2);
const barWidth = Math.max(6, 60 - distance / 5);
item.style.transform = `scale(${scale})`;
item.style.opacity = opacity;
item.style.setProperty('--bar-width', barWidth + 'px');
item.style.setProperty('--bar-color', distance < 50 ? '#333' : '#aaa');
});
}
document.addEventListener('mousemove', updateScale);
// Initial positioning
updateScale({ clientY: window.innerHeight / 2 });
</script>
</body>
</html>
================================================
FILE: assets/site/index3.html
================================================
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Interactive Hacker Laws Stack</title>
<style>
body {
display: flex;
justify-content: center;
align-items: center;
height: 100vh;
background-color: #f5f5f5;
margin: 0;
font-family: Arial, sans-serif;
overflow: hidden;
}
#stack-container {
width: 400px;
height: 500px;
border: 1px solid #ddd;
border-radius: 8px;
background-color: #fff;
box-shadow: 0 2px 10px rgba(0,0,0,0.1);
padding: 10px;
overflow: hidden;
position: relative;
}
#stack {
position: absolute;
width: 100%;
}
.law-item {
text-align: left;
padding: 2px 4px;
transition: transform 0.2s ease, opacity 0.2s;
transform-origin: left;
font-size: 15px;
color: #333;
margin: 4px 0;
position: relative;
display: flex;
align-items: center;
}
.law-item::before {
content: '';
display: block;
width: var(--bar-width, 6px);
height: 6px;
border-radius: 3px;
background-color: var(--bar-color, #aaa);
margin-right: 10px;
transition: width 0.2s, background-color 0.2s;
}
</style>
</head>
<body>
<div id="stack-container">
<div id="stack"></div>
</div>
<script>
const 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", "Hofstadter's Law", "Hutber's Law",
"The Hype Cycle & Amara's Law", "Hyrum's Law (The Law of Implicit Interfaces)",
"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", "The Dilbert Principle", "The Pareto Principle (The 80/20 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"
];
const stack = document.getElementById('stack');
const stackContainer = document.getElementById('stack-container');
const maxZoom = 1.8;
const minZoom = 0.5;
let offsetY = 0;
laws.forEach(title => {
const div = document.createElement('div');
div.className = 'law-item';
div.innerText = title;
stack.appendChild(div);
});
function updateScale() {
const items = document.querySelectorAll('.law-item');
items.forEach(item => {
const itemRect = item.getBoundingClientRect();
const containerRect = stackContainer.getBoundingClientRect();
const itemCenter = (itemRect.top + itemRect.bottom) / 2;
const containerCenter = (containerRect.top + containerRect.bottom) / 2;
const distance = Math.abs(containerCenter - itemCenter);
const scale = Math.max(maxZoom - distance / 120, minZoom);
const opacity = Math.max(1 - distance / 300, 0.3);
const barWidth = Math.max(6, 60 - distance / 3);
item.style.transform = `scale(${scale})`;
item.style.opacity = opacity;
item.style.setProperty('--bar-width', barWidth + 'px');
item.style.setProperty('--bar-color', distance < 50 ? '#333' : '#aaa');
});
}
stackContainer.addEventListener('wheel', (e) => {
e.preventDefault();
offsetY = (offsetY + e.deltaY) % stack.scrollHeight;
if (offsetY < 0) offsetY += stack.scrollHeight;
stack.style.top = `${-offsetY}px`;
updateScale();
});
document.addEventListener('mousemove', updateScale);
updateScale();
</script>
</body>
</html>
================================================
FILE: assets/site/index4.html
================================================
<!--
Interactive Hacker Laws Stack - Specification:
1. User Experience:
- Display a vertically scrolling list of items ("laws") in a visually appealing, interactive format.
- The list infinitely loops seamlessly; scrolling beyond the first or last item cycles continuously.
- Mouse scrolling moves the entire list vertically within a fixed viewport (no internal scrollbar visible).
- The item under the mouse cursor smoothly scales up (zooms) and becomes clearly highlighted.
- Items further from the cursor scale down smoothly, fade out gradually, and become visually less prominent.
- To the left of each text item, a horizontal bar visually represents the focus, forming a bell-curve-like effect.
The bar is smallest (circular) when far from the cursor, and smoothly expands (rectangular with rounded corners) when close.
2. Sources:
- Original Interaction Design Inspiration: https://press.stripe.com/
- Data Source (list of "Hacker Laws"): https://github.com/dwmkerr/hacker-laws/
3. Technical Details:
- Implemented using plain HTML, CSS, and JavaScript without third-party libraries.
- Clearly defined parameters for customization:
- `maxZoom`: maximum scale factor for the item closest to the cursor.
- `minZoom`: minimum scale factor for items furthest from the cursor.
- Styling is clean, minimalist, and customizable via CSS variables.
This specification allows easy adjustments, maintenance, and future enhancements of the interactive list.
-->
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Interactive Hacker Laws Stack</title>
<style>
body {
display: flex;
justify-content: center;
align-items: center;
height: 100vh;
background-color: #f5f5f5;
margin: 0;
font-family: Arial, sans-serif;
overflow: hidden;
}
#stack-container {
width: 400px;
height: 500px;
border: 1px solid #ddd;
border-radius: 8px;
background-color: #fff;
box-shadow: 0 2px 10px rgba(0,0,0,0.1);
padding: 10px;
overflow: hidden;
position: relative;
}
#stack {
position: absolute;
width: 100%;
}
.law-item {
text-align: left;
padding: 2px 4px;
transition: transform 0.2s ease, opacity 0.2s;
transform-origin: left;
font-size: 15px;
color: #333;
margin: 4px 0;
position: relative;
display: flex;
align-items: center;
}
.law-item::before {
content: '';
display: block;
width: var(--bar-width, 6px);
height: 6px;
border-radius: 3px;
background-color: var(--bar-color, #aaa);
margin-right: 10px;
transition: width 0.2s, background-color 0.2s;
}
</style>
</head>
<body>
<div id="stack-container">
<div id="stack"></div>
</div>
<script>
const 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", "Hofstadter's Law", "Hutber's Law",
"The Hype Cycle & Amara's Law", "Hyrum's Law (The Law of Implicit Interfaces)",
"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", "The Dilbert Principle", "The Pareto Principle (The 80/20 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"
];
const stack = document.getElementById('stack');
const stackContainer = document.getElementById('stack-container');
const maxZoom = 1.8;
const minZoom = 0.5;
let offsetY = 0;
// Create seamless infinite scrolling
const extendedLaws = [...laws, ...laws, ...laws];
extendedLaws.forEach(title => {
const div = document.createElement('div');
div.className = 'law-item';
div.innerText = title;
stack.appendChild(div);
});
const totalHeight = stack.scrollHeight / 3;
stack.style.top = `-${totalHeight}px`;
offsetY = totalHeight;
function updateScale(e) {
const items = document.querySelectorAll('.law-item');
items.forEach(item => {
const itemRect = item.getBoundingClientRect();
const distance = e.clientY ? Math.abs(e.clientY - (itemRect.top + itemRect.bottom) / 2) : 0;
const scale = Math.max(maxZoom - distance / 120, minZoom);
const opacity = Math.max(1 - distance / 300, 0.3);
const barWidth = Math.max(6, 60 - distance / 3);
item.style.transform = `scale(${scale})`;
item.style.opacity = opacity;
item.style.setProperty('--bar-width', barWidth + 'px');
item.style.setProperty('--bar-color', distance < 50 ? '#333' : '#aaa');
});
}
stackContainer.addEventListener('wheel', (e) => {
e.preventDefault();
offsetY += e.deltaY;
if (offsetY >= totalHeight * 2) offsetY -= totalHeight;
if (offsetY < totalHeight) offsetY += totalHeight;
stack.style.top = `-${offsetY}px`;
updateScale(e);
});
stackContainer.addEventListener('mousemove', updateScale);
// Initial scale update
updateScale({ clientY: window.innerHeight / 2 });
</script>
</body>
</html>
================================================
FILE: scripts/prepare-markdown-for-ebook.sh
================================================
#!/usr/bin/env bash
# Fail on errors.
set -e -o pipefail
# Check if parameters are provided
input="$1"
output="$2"
if [ -z "${input}" ] || [ -z "${output}" ]; then
echo "usage: $(basename "$0") <input> <output>" >&2
echo " input: source markdown file (usually README.md)" >&2
echo " output: output markdown file (usually hacker-laws.md)" >&2
exit 1
fi
# Grab env vars used to configure output, fail if required are missing.
export date="${DATE:-$(date +%F)}"
export version="${VERSION?error: VERSION must be set}"
# Update the input file to an intermedate.
intermediate="${input}.temp"
cat <<EOF > "${intermediate}"
---
title: "Hacker Laws"
author: "Dave Kerr, github.com/dwmkerr/hacker-laws"
subtitle: "Laws, Theories, Principles, and Patterns that developers will find useful. ${VERSION}, ${DATE}."
version: ${VERSION}
---
EOF
cat "${input}" >> "${intermediate}"
DATE="${date}" VERSION="${version}" envsubst < "${intermediate}" > "${output}"
# Use a single `sed` command to clean up unwanted lines and emojis in one pass.
sed -e '/💻📖.*/d' \
-e 's/❗/Warning/g' \
-e '/^\[Translations.*/d' \
-e '/\*.*/d' \
-e '/ \*.*/d' \
-e '/## Translations/,$d' "${output}" > "${intermediate}"
mv "${intermediate}" "${output}"
echo "${output} prepared successfully."
================================================
FILE: translations/es-ES.md
================================================
# 💻📖 hacker-laws
Leyes, Teorías, Principios y Patrones que los desarrolladores encontrarán útiles.
[traducciones](#translations): [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇫🇷](./translations/fr.md) [🇮🇹](./translations/it-IT.md) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇹🇷](./translations/tr.md) [🇮🇩](./translations/id.md) [🇯🇵](./translations/jp.md) [🇵🇱](./translations/pl.md) [🇻🇳](./translations/vi.md)
¿Te gusta este proyecto? Por favor, considera [Esponsorizarme](https://github.com/sponsors/dwmkerr)!
---
<!-- vim-markdown-toc GFM -->
* [Introducción](#introduccion)
* [Leyes](#leyes)
* [Ley de Amdahl](#ley-de-amdahl)
* [Ley de Brooks](#ley-de-brooks)
* [Ley de Conway](#ley-de-conways)
* [Ley de Cunningham](#ley-de-cunningham)
* [Número de Dunbar](#numero-de-dunbar)
* [Ley de Gall](#ley-de-gall)
* [Cuchilla de Hanlon](#cuchilla-de-hanlon)
* [Ley de Hofstadter](#ley-de-hofstadter)
* [Ley de Hutber](#ley-de-hutber)
* [El Ciclo de Sobreexpectación y la Ley de Amara](#el-ciclo-de-sobreexpectacion-y-la-ley-de-amara)
* [Ley de Hyrum (La Ley de las Interfaces Implícitas)](#ley-de-hyrum-la-ley-de-las-interfaces-implicitas)
* [Ley de Metcalfe](#ley-de-metcalfe)
* [Ley de Moore](#ley-de-moore)
* [Ley de Murphy / Ley de Sod](#ley-de-murphy--ley-de-sod)
* [Ley de Parkinson](#ley-de-parkinson)
* [Efecto de Optimización Prematura](#efecto-de-optimizacion-prematura)
* [Ley de Putt](#ley-de-putt)
* [Ley de Reed](#ley-de-reed)
* [Ley de Conservación de Complejidad (Ley de Tesler)](#ley-de-conservacion-de-complejidad-ley-de-tesler)
* [Ley de Abstracciones Permeables](#ley-de-abstracciones-permeables)
* [Ley de la Trivialidad](#ley-de-la-trivialidad)
* [Filosofía Unix](#filosofia-unix)
* [El Modelo Spotify](#el-modelo-spotify)
* [Ley de Wadler](#ley-de-wadler)
* [Principios](#principios)
* [El Principio de Dilbert](#el-principio-de-dilbert)
* [El Principio de Pareto (La Regla 80/20)](#el-principio-de-pareto-la-regla-8020)
* [El Principio de Peter](#el-principio-de-peter)
* [El Principio de la Robustez (Ley de Postel)](#el-principio-de-la-robustez-ley-de-postel)
* [SOLID](#solid)
* [El Principio de Única Responsabilidad](#el-principio-de-unica-responsabilidad)
* [El Principio Abierto/Cerrado](#el-principio-abierto-cerrado)
* [El Principio de Sustitución de Liskov](#el-principio-de-sustitucion-de-liskov)
* [El Principio de Segregación de Interfaz](#el-principio-de-segregacion-de-interfaz)
* [El Principio de Inversión de Dependencia](#el-principio-de-inversion-de-dependencia)
* [El Principio DRY](#el-principio-dry)
* [El Principio KISS](#el-principio-kiss)
* [YAGNI](#yagni)
* [Lista de Lectura](#lista-de-lectura)
* [POR-HACER](#por-hacer)
<!-- vim-markdown-toc -->
## Introducción
Hay montones de leyes que la gente discute cuando habla sobre desarrollo. Este repositorio es una referencia y un resumen de algunos de los más conocidos. Por favor, ¡comparte y sube tus PRs!
❗: Este repositorio contiene una explicación sobre algunas leyes, principios y patrones, pero no _defendemos_ ninguno de ellos. Si estos pueden ser aplicados o no siempre será materia de debate y muy dependiente de en qué estés trabajando.
## Leyes
¡Y aquí vamos!
### Ley de Amdahl
[Ley de Amdahl en Wikipedia](https://es.wikipedia.org/wiki/Ley_de_Amdahl)
> La ley de Amdahl se puede interpretar de manera más técnica, pero en términos simples, significa que es el algoritmo el que decide la mejora de velocidad, no el número de procesadores. Finalmente se llega a un momento que no se puede paralelizar más el algoritmo.
Mejor lo ilustramos con un ejemplo. Si un programa se compone de dos partes, la parte A debe ser ejecutada en un solo procesador y la parte B puede ser paralelizada, entonces vemos que agregamos múltiples procesadores al sistema en ejecución ese programa puede solo tener un beneficio limitado. Este puede potencialmente mejorar mucho la velocidad de la parte B - pero la velocidad de la parte A se mantendrá sin cambios.
El diagrama de abajo muestra algunos ejemplos de mejoras potenciales en velocidad:
*(Imagen de Referencia: Por Daniels220 en Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)*
Como podemos ver, incluso un programa el cual es un 50% paralelizable se beneficiará muy poco más allá de 10 unidades de procesamiento, mientras que un programa el cual es 95% paralelizable todavía puede alcanzar mejoras significativas de velocidad con más de mil unidades de procesamiento.
A medida que la [Ley de Moore](#ley-de-moore) se ralentiza y la aceleración de la velocidad del procesador individual disminuye, la paralelización es la clave para incrementar el rendimiento.La programación de gráficos es un excelente ejemplo: con la informática moderna basada en Shader, píxeles individuales o fragmentos pueden ser renderizados en paralelo. Este es el porqué las tarjetas gráficas modernas en ocasiones disponen de miles de núcleos de procesamiento (GPUs o Unidades de Shader).
Vea también:
- [Ley de Brooks](#ley-de-brooks)
- [Ley de Moore](#ley-de-moore)
### Ley de Brooks
[Ley de Brooks en Wikipedia](https://es.wikipedia.org/wiki/Ley_de_Brooks)
> Cuando se incorpora una persona en un proyecto, éste se ralentiza en lugar de acelerarse. Brooks también afirmó que "Nueve mujeres no pueden tener un bebé en un mes".
Esta ley sugiere que en muchos casos, intentar acelerar la entrega de un proyecto el cual ya va tarde, agregando más personas, hará que la entrega vaya aún más tarde. Brooks clarifica que esto es una simplificación, sin embargo, el razonamiento general es que el tiempo de aceleración de nuevos recursos y la sobrecarga de comunicación, en el inmediato corto plazo hace que la velocidad caiga. También, muchas tareas pueden no ser divisibles, es decir que pueden no ser fácilmente distribuibles entre más personas, significando que el potencial incremento de velocidad es incluso menor.
La frase común en entregas "Nueve mujeres no pueden tener un bebé en un mes" está relacionada a la Ley de Brooks, en particular, al hecho de que algunos tipos de trabajos no son divisibles ni paralelizables.
Este es el tema central del libro '[El Mítico Hombre Mes](#lista-de-lectura)'.
Vea también:
- [Marcha de la Muerte](#todo)
- [Lista de Lectura: El Mítico Hombre Mes](#reading-list)
### Ley de Conway
[La Ley de Conway en Wikipedia](https://es.wikipedia.org/wiki/Ley_de_Conway)
Esta ley sugiere que los límites técnicos de un sistema reflejan la estructura de la organización. Es comúnmente referido a cuando se observan mejoras de una organización, la Ley de Conway sugiere que si una organización es estructurada en muchas unidades pequeñas y desconectadas, el software que producirá será así. Si una organización es construída más entorno a soluciones 'verticales' las cuales están orientadas alrededor de características o servicios, los sistemas de software también reflejarán esto.
Vea también:
- [El Modelo Spotify](#el-modelo-spotify)
### Ley de Cunningham
[Ley de Cunningham en Wikipedia](https://meta.wikimedia.org/wiki/Cunningham%27s_Law/es)
> La mejor forma de obtener la respuesta correcta en Internet no es hacer una pregunta, es enviar la respuesta errónea.
Acorde a Steven McGeady, Ward Cunningham le aconsejó a principios de los 80: "La mejor forma de obtener la respuesta correcta en Internet no es hacer una pregunta, es enviar una respuesta incorrecta." McGeady lo llamó la Ley de Cunningham, sin embargo Cunningham niega su propiedad diciendo que es una cita errónea. Aunque originalmente se refiere a las interacciones en Usenet, la ley ha sido usada para describir como otras comunidades online funcionan (e.g., Wikipedia, Reddit, Twitter, Facebook).
Vea también:
- [XKCD 386: "Duty Calls" (El Deber Llama)](https://xkcd.com/386/)
### El Número de Dunbar
[El Número de Dunbar en Wikipedia](https://es.wikipedia.org/wiki/N%C3%BAmero_de_Dunbar)
"El número de Dunbar es un límite cognitivo sugerido sobre el número de personas con las que puedes mantener relaciones sociables estables- relaciones en las que un individuo sabe quien es la otra persona and cómo cada persona se relaciona con cada una de las otras personas." Hay algún desacuerdo sobre el número exacto. "... [Dunbar] propuso que los humanos pueden mantener cómodamente solo 150 relaciones estables." El puso el número dentro de un contexto más social, "el número de personas con las que no sentirías vergüenza de invitarlas a tomar una copa
"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, "la cantidad de personas de las que no te sentirías avergonzado por unirte sin invitación a tomar una copa si te topas con ellas en un bar." Estima que el número puede rondar generalmente entre 100 y 250.
Al igual que relaciones estables entre individuos, la relación de un desarrollador con su código base toma esfuerzo mantenerla. Cuando afrontas un gran número de proyectos complicados o creas muchos proyectos, nos apoyamos en convenciones, políticas y modelamos procedimientos para escalar. El número de Dunbar no es solo importante para tener en mente como una oficina crece, también cuando configuramos el alcance de los esfuerzos de un equipo o decidimos cuando debemos invertir en herramientas para asistir en el modelado y automatizar el sobregasto logístico. Poniendo el número en el contexto de ingeniería, es el número de proyectos (o complejidad normalizada de un único proyecto) para los cuales podrías sentirte seguro de unirte para las rondas de soporte telefónico.
Vea también:
- [Ley de Conway](#ley-de-conway)
### Ley de Gall
[Ley de Gall en Wikipedia (inglés)](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law)
> Un sistema complejo que funciona ha sido evolucionado invariablemente desde un sistema simple que funcionaba. Un sistema complejo diseñado desde cero nunca funcionará y no puede ser arreglado para que funcione. Tienes que comenzar de nuevo con un sistema simple que funcione.
>
> ([John Gall](https://en.wikipedia.org/wiki/John_Gall_(author)))
La Ley de Gall implica que los intentos de _diseñar_ un sistema altamente complejo tenderán siempre a fallar. Sistemas altamente complejos son raramente construidos de una sola vez, estos suelen ser evoluciones de sistemas mucho más simples.
El ejemplo clásico es la World Wide Web (WWW). En su estado actual, es un sistema altamente complejo. Sin embargo, esta fue definida inicialmente como una forma simple de compartir contenido entre instituciones académicas. Esta fue un éxito cumpliendo sus objetivos y evolucionó para llegar a ser más compleja con el tiempo.
Vea también:
- [KISS (Keep It Simple, Stupid)](#el-principio-kiss)
### La Navaja de Hanlon
[La Navaja de Hanlon en Wikipedia](https://es.wikipedia.org/wiki/Principio_de_Hanlon)
> Nunca atribuyas a la malicia lo que puede ser adecuadamente explicado por la estupidez.
>
> Robert J. Hanlon
Este principio sugiere que las acciones resultantes en un resultado negativo no fueron resultado de una mala intención. En su lugar el resultado negativo es mejor atribuído a que esas acciones y/o el impacto no fueron completamente entendidos.
### Ley de Hofstadter
[Ley de Hofstadter en Wikipedia](https://es.wikipedia.org/wiki/Ley_de_Hofstadter)
> Siempre lleva más tiempo de lo que esperas, incluso si tienes en cuenta la Ley de Hofstadter.
>
> (Douglas Hofstadter)
Quizás hayas oído esta ley referida a cuando se busca estimar el tiempo que tomará algo. Esto parece una verdad absoluta en el desarrollo de software donde tendemos a no ser muy buenos estimando con precisión cuanto tiempo tomará entregar algo.
Esto proviene del libro '[Gödel, Escher, Bach: An Eternal Golden Braid](#lista-de-lectura)'.
Vea también:
- [Lista de lectura: Gödel, Escher, Bach: An Eternal Golden Braid](#lista-de-lectura)
### Ley de Hutber
[Ley de Hutber en Wikipedia (inglés)](https://en.wikipedia.org/wiki/Hutber%27s_law)
> Mejorar signfica deteriorar.
>
> ([Patrick Hutber (inglés)](https://en.wikipedia.org/wiki/Patrick_Hutber))
Esta ley sugiere que las mejoras realizadas en un sistema llevarán a su deterioro en otras partes, u ocultará otros deterioros, llevando a una degradación total del estado actual del sistema.
Por ejemplo, un decremento en la latencia de respuesta para un end-point particular podría causar problemas de rendimiento y capacidad de procesamiento más adelante en el flujo de peticiones, afectando a un subsistema completamente diferente.
### El Ciclo de Sobreexpectación y La Ley de Amara
[El Ciclo de Sobreexpectación](https://es.wikipedia.org/wiki/Ciclo_de_sobreexpectaci%C3%B3n)
> Tendemos a sobreestimar el efecto de una tecnología a corto plazo y subestimar su efecto a largo plazo.
>
> (Roy Amara)
El Ciclo de Sobreexpectación es una representación visual de la excitación y desarrollo de tecnología a lo largo del tiempo, originalmente producido por Gartner. Se explica mejor de forma visual:
*(Referencia de Imagen: Por Jeremykemp en Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)*
En pocas palabras, el ciclo sugiere que hay una típica burbuja de excitación alrededor de cada nueva tecnología y su impacto potencial. Los equipos a veces saltan rápidamente a emplear estas tecnologías y a veces se encuentran a sí mismos decepcionados con los resultados. Esto puede ser porque la tecnología no es aún lo suficientemente madura, o las aplicaciones del mundo real no están completamente desarrolladas. Después de cierto tiempo, las capacidades de la tecnología se incrementan y las oportunidades de ser empleada de forma práctica aumentan permitiendo a los equipos ser finalmente productivos. La frase de Roy Amara resume este hecho de forma breve - "Tendemos a sobreestimar el efecto de una tecnología a corto plazo y subestimarla a largo plazo".
### Ley de Hyrum (La Ley de las Interfaces Implícitas)
[Ley de Hyrum (inglés)](http://www.hyrumslaw.com/)
> Con un número suficiente de usuarios de una API,
> no importa que prometas en el contrato:
> alguien dependerá de todos los comportamientos observables
> de tu sistema.
>
> (Hyrum Wright)
La Ley de Hyrum establece que cuando tienes un _número grande y suficiente de consumidores_ de una API, todos los comportamientos de la API (incluso aquellos no definidos como parte del contrato público) llegarán de forma eventual a ser dependencia de alguien. Un ejemplo trivial pueden ser los elementos no-funcionales como el tiempo de respuesta de una API. Un ejemplo más sutil puede ser qué consumidores están dependiendo en la aplicación de una expresión regular sobre un mensaje de error para determinar el *tipo* de error de una API. Incluso si el contrato público de la API no establece nada acerca del contenido del mensaje de error indicando a los usuarios que deben emplear un código de error, _algunos_ usuarios usarán el mensaje y cambiar el mensaje esencialmente romperá la API para estos usuarios.
Vea también:
- [La Ley de las Abstracciones Permeables](#la-ley-de-las-abstracciones-permeables)
- [XKCD 1172](https://xkcd.com/1172/)
### Ley de Metcalfe
[Ley de Metcalfe en Wikipedia (inglés)](https://en.wikipedia.org/wiki/Metcalfe's_law)
> En teoría de redes, el número en el que un sistema crece es aproximadamente el cuadrado del número de usuarios de ese sistema.
Esta ley está basada en el número de posibles conexiones por pares dentro de un sistema y está muy relacionado con [La Ley de Reed](#ley-de-reed). Odlyzko y otros han argumentado que ambas leyes (Reed y Metcalfe) exageran el valor de un sistema por no tener en cuenta los límites de la cognición humana en efectos de redes; vea [El Número de Dunbar](#numero-de-dunbar).
Vea también:
- [Ley de Reed](#ley-de-reed)
- [Número de Dunbar](#numero-de-dunbar)
### Ley de Moore
[Ley de Moore en Wikipedia](https://es.wikipedia.org/wiki/Ley_de_Moore)
> El número de transistores en un circuito integrado se dobla aproximadamente cada dos años.
A veces empleado para ilustrar la velocidad pura a la que un semiconductor y la tecnología de chips ha mejorado, la predicción de Moore probó ser altamente precisa desde los 70 hasta finales de la primera década de 2000. En los años recientes, la tendencia ha cambiado ligeramente, parcialmente debido a [las limitaciones físicas en el grado en el que los componentes pueden ser miniaturizados (inglés)](https://en.wikipedia.org/wiki/Quantum_tunnelling). Sin embargo, los avances en la paralelización y potencialmente los cambios revolucionarios en la tecnología de semiconductores y computación cuántica puedan significar que la Ley de Moore continúe siendo cierta en las siguientes décadas.
### Ley de Murphy / Ley de Sod
[Ley de Murphy en Wikipedia](https://es.wikipedia.org/wiki/Ley_de_Murphy)
> Si algo puede ir mal, irá mal.
Relacionado con [Edward A. Murphy, Jr](https://es.wikipedia.org/wiki/Edward_A._Murphy_Jr.) la _Ley de Murphy_ establece que si algo puede ir mal, irá mal.
Este dicho es muy común entre desarrolladores. A veces algo inesperado sucede cuando se desarrolla, se hacen pruebas o incluso en producción. Esto puede relacionarse también a la (más común en inglés británico) _Ley de Sod_:
> Si algo puede ir mal, irá mal, en el peor momento posible.
Estas leyes son generalmente empleadas en sentido cómico. Sin embargo, tales fenómenos como la [_Sesgo de Confirmación_](#por-hacer) y [_Sesgo de Selección_](#por-hacer) pueden llevar a la gente a sobre-enfatizar estas leyes (la mayoría de las veces cuando las cosas funcionan, estas pasan sin tenerse en cuenta, mientras que los fallos son muy notalbes y entran más en las conversaciones).
Vea también:
- [Sesgo de Confirmación](#por-hacer)
- [Sesgo de Selección](#por-hacer)
### Ley de Parkinson
[Ley de Parkinson en Wikipedia](https://es.wikipedia.org/wiki/Ley_de_Parkinson)
> El trabajo se expande hasta llenar el tiempo disponible para que se termine.
En su contexto original, esta Ley se basó en estudios de burocracias. Esta podía ser aplicada de forma pesimista a las iniciativas de desarrollo de software, la teoría sería que los equipos serán ineficientes hasta que la fecha de entrega esté cerca, entonces se apresurarán a completar el trabajo para la entrega, haciendo la fecha de entrega real de algún modo arbitraria.
Si esta ley se combina con la [Ley de Hofstadter](#ley-de-hofstadter), un punto de vista incluso más pesimista es alcanzado - el trabajo se expandirá hasta rellenar el tiempo disponible para su compleción y *aún tomará más tiempo del esperado*.
Vea también:
- [Ley de Hofstadter](#ley-de-hofstadter)
### Efecto de Optimización Prematura
[Optimización Prematura en Wikipedia](https://es.wikipedia.org/wiki/Optimizaci%C3%B3n_de_software#Cu%C3%A1ndo_optimizar)
> Debemos olvidar las pequeñas eficiencias, por ejemplo, el 97% del tiempo: la optimización prematura es la raíz de todos los males.
>
> [(Donald Knuth, diciembre de 1974)](https://twitter.com/realdonaldknuth)
En el documento de Donald Knuth titulado [Programación Estructurada con Mandatos Go To (inglés)](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements), escribió: "Los programadores desperdician enormes cantidades de tiempo pensando o preocupándose acerca de la velocidad de partes no-críticas de sus programas, y esos intentos de eficiencia en realidad tienen un impacto negativo cuando consideramos la depuración o el mantenimiento. Debemos olvidar las pequeñas eficiencias, por ejemplo, el 97% del tiempo: **la optimización prematura es la raíz de todos los males**. Aunque no debemos dejar pasar nuestras oportunidades en ese crítico 3%."
Sin embargo, _Premature Optimization_ puede ser definido (en términos menos cargados) como nosotros sabemos lo que tenemos que hacer.
### Ley de Putt
[Ley de Putt (inglés)](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat)
> La Tecnología es dominada por dos tipos de personas, aquellos quienes comprenden lo que no controlan y aquellos quienes controllan lo que no entienden.
La Ley de Putt a veces es seguida por el Corolario de Putt:
> Cada jerarquía técnica, con el tiempo, desarrolla una inversión de competencia.
Estos mandatos sugieren que debido a varios criterios de selección y tendencias en cómo los grupos se organizan, habrá un número de personas cualificadas en los niveles de trabajo de una organización técnica y una cantidad de personas en roles directivos que no son conscientes de las complejidades y desafíos del trabajo que están manejando. Esto puede ser debido al fenómenos tales como [El Principio de Peter](#el-principio-de-peter) o [El Principio de Dilbert](#el-principio-de-dilbert).
Sin embargo, debe enfatizarse que leyes como esta son generalizaciones amplias y pueden aplicarse a _algunos_ tipos de organizaciones y no a otras.
Vea también:
- [El Principio de Peter](#el-principio-de-peter)
- [El Principio de Dilbert](#el-principio-de-dilbert)
### La Ley de Reed
[La Ley de Reed en Wikipedia (inglés)](https://en.wikipedia.org/wiki/Reed's_law)
> La utilidad de redes grandes, particularmente redes sociales, escala exponencialmente con el tamaño de la red.
Esta ley está basada en la teoría de grafos, donde la utilidad escala como el número de posibles sub-grupos, el cuál es más rápido que el número de participantes o el número de posibles conexiones p
Esta ley se basa en la teoría de grafos, donde la utilidad se escala como el número de subgrupos posibles, que es más rápido que el número de participantes o el número de posibles conexiones por pares. Odlyzko y otros han argumentado que la Ley de Reed exagera la utilidad del sistema al no tener en cuenta los límites de la cognición humana sobre los efectos de la red; ver [El Número de Dunbar](#numero-de-dunbar).
See also:
- [La Ley de Metcalfe's Law](#metcalfes-law)
- [Número de Dunbar](#numero-de-dunbar)
### Ley de Conservación de Complejidad (Ley de Tesler)
[La Ley de Conservación de Complejidad en Wikipedia (inglés)](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity)
Esta ley establece que hay una cierta cantidad de complejidad en un sistema la cuál no puede ser reducida.
Cierta complejidad en un sistema puede ser 'involuntaria'. Es consecuencia de una estructura deficiente, errores o tan solo un mal modelo de un problema a resolver. La complejidad involuntaria puede ser reducida (o eliminada). Sin embargo, cierta complejidad es 'intrínseca' como consecuencia de la complejidad inherente de un problema que se está resolviendo. Esta complejidad puede ser desplazada, pero no eliminada.
Un elemento interesate de esta ley es la sugerencia de que incluso simplificando el sistema entero, la complejidad intrínseca no se reduce, esta se _desplaza hacia el usuario_, el cuál debe comportarse de una forma compleja.
### Ley de las Abstracciones Permeables
[La Ley de las Abstracciones Permeables en Joel on Software (inglés)](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/)
> Toda abstracción no trivial, en algún grado, es permeable.
>
> ([Joel Spolsky](https://twitter.com/spolsky))
Esta ley establece que las abstracciones, las cuales son generalmente usadas en computación para simplificar el trabajo con sistemas complicados, en ciertas situaciones 'filtrarán' sus elementos a un sistema subyacente, haciendo que la abstracción se comporte de una forma inesperada.
Un ejemplo puede ser la carga de un fichero y lectura de sus contenidos. Las APIs del sistema de ficheros son una _abstracción_ del bajo nivel de los sistemas del kernel, los cuales son en sí mismos abstracciones de los procesos físicos relacionados con el cambio de información en un disco magnético (o memoria flash para un SSD). En la mayoría de los casos, funcionará la abstracción de tratar al fichero como un flujo de datos binarios. Sin embargo, para un disco magnético, leer datos secuenciales puede ser *significativamente* más rápido que los accesos aleatorios (debido al aumento de la sobrecarga de fallas), pero no para un disco SSD donde este aumento no estará presente. Los detalles subyacentes necesitarán ser entendidos para tratar cada caso (por ejemplo, índices de base de datos son estructurados para reducir la sobrecarga del acceso aleatorio), la abstracción 'filtra' detalles de la implementación al desarrollador que pueda necesitar tener en cuenta.
El ejemplo anterior puede llegar a ser aún más complejo cuando _más_ abstracciones sean introducidas. El sistema operativo Linux permite acceder a ficheros en red pero representados de forma local como ficheros 'normales'. Esta abstracción 'filtrará' si hay errores de red. Si un desarrollador trata estos ficheros como 'normales', sin considerar el hecho de que puedan estar sujetos a latencia de red y fallos, las soluciones serán defectuosas.
El artículo que describe esta ley sugiere que una dependenica excesiva de abstracciones, combinada con un entendimiento deficiente del proceso subyacente, en realidad hace que tratar con el problema sea _más_ complejo en algunos casos.
Vea también:
- [Ley de Hyrum](#ley-de-hyrum-la-ley-de-las-interfaces-implicitas)
Ejemplos del Mundo-Real:
- [Inicio lento en Photoshop (inglés)](https://forums.adobe.com/thread/376152) - un problema que encontré en el pasado. Photoshop podría tener un inicio lento, algunas veces tomando incluso minutos. Parece que el problema fue debido a que al inicio lee cierta información sobre la impresora por defecto. Sin embargo, si la impresora está en red, esto puede tomar mucho tiempo. La _abstracción_ de una impresora en red siendo presentada al sistema de forma similar a una impresora local causó un problema para usuarios en situaciones de conectividad de red deficiente.
### Ley de la Trivialidad
[Ley de la Trivialidad en Wikipedia (inglés)](https://en.wikipedia.org/wiki/Law_of_triviality)
Esta ley sugiere que los grupos invertirán mucho más tiempo y atención a problemas triviales y cosméticos que a problemas serios y sustanciales.
El ejemplo común y ficticio usado para ilustrarlo es que un comité aprobando planes para una planta nuclear invertirá la mayor parte del tiempo discutiendo la estructura del aparcamiento de bicicletas que diseños mucho más importantes para la planta nuclear en sí misma. Puede ser difícil hacer aportes valiosos en las discusiones sobre temas muy grandes y complejos sin un alto grado de experiencia y preparación en el tema. Sin embargo, la gente quiere ser vista contribuyendo de forma valiosa. De ahí la tendencia a enfocarse demasiado en detalles pequeños, los cuales pueden ser razonados fácilmente, pero no necesariamente de particular importancia.
El ejemplo ficticio de arriba nos lleva al uso del término 'Aparcamiento de Bicicletas' (Bike Shedding) como una expresión para el desperdicio del tiempo en detalles triviales.
### Filosofía Unix
[La Filosofía Unix en Altenwald](https://altenwald.org/2008/09/22/filosofia-unix/)
La Filosofía Unix es que los componentes de software debe ser pequeños y enfocados en hacer tan solo una cosa bien. Esto puede hacer más fácil construir sistemas a través de la composición conjunta de pequeñas, simples y bien definidas unidades mejor que usar programas grandes, complejos y multi-propósito.
Prácticas modernas como 'Arquitectura de Microservicios' pueden ser pensadas como una aplicación de esta ley, donde los servicios son pequeños, enfocados y hacen una cosa específica, permitiendo componer comportamientos más complejos compuestos de bloques de construcción simples.
### El Modelo Spotify
[El Modelo Spotify en Spotify Labs (inglés)](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/)
El Modelo Spotify es un enfoque a una estructura de organización la cual ha sido popularizada por 'Spotify'. En este modelo, los equipos son organizados alrededor de características en lugar de tecnologías.
El Modelo Spotify también popularizó los conceptos de Tribus, Gremios y Capítulos, los cuales son otros componentes de su estructura de organización.
### Ley de Wadler
[Ley de Wadler en wiki.haskell.org (inglés)](https://wiki.haskell.org/Wadler's_Law)
> En cualquier diseño de lenguaje, el total de tiempo invertido en discutir una característica en su lista es proporcional a dos elevado a la potencia de su posición:
>
> 0. Semántica
> 1. Sintaxis
> 2. Sintaxis Léxica
> 3. Sintaxis Léxica de Comentarios
>
> (En pocas palabras, por cada hora invertida en semántica, 8 horas serán invertidas en la sintaxis de los comentarios).
Similar a [La Ley de la Trivialidad](#ley-de-la-trivialidad), la Ley de Walder establece que cuando un se diseña un lenguaje, la cantidad de horas invertida en las estructuras del lenguaje es desproporcionadamente alta en comparación a la importancia de estas características.
Vea también:
- [La Ley de la Trivialidad](#ley-de-la-trivialidad)
## Principios
Los Principios son generalmente más propensos a ser pautas relacionadas al diseño.
### El Principio de Dilbert
[El Principio de Dilbert en Wikipedia (inglés)](https://en.wikipedia.org/wiki/Dilbert_principle)
> Las compañías tienden sistémicamente a promocionar empleados incompetentes a dirección para eliminarlos del flujo de trabajo.
>
> _Scott Adams_
Un concepto de administración desarrollado por Scott Adams (creador de la tira cómica de Dilbert), el Principio de Dilbert está inspirado por [El Principio de Peter](#el-principio-de-peter). Bajo el Principio de Dilbert, los empleados que nunca fueron competentes son promocionados a cargos directivos para limitar el daño que pueden hacer. Adams primero explicó el principio en 1995 en un artículo del Wall Street Journal y lo expandió en su libro de negocios publicado en 1996, [The Dilbert Principle (inglés)](#lista-de-lectura).
Vea también:
- [El Principio de Peter](#el-principio-de-peter)
- [Ley de Putt](#ley-de-putt)
### El Principio de Pareto (La Regla 80/20)
[El Principio de Pareto en Wikipedia](https://es.wikipedia.org/wiki/Principio_de_Pareto)
> La mayoría de cosas en la vida no se distribuyen de forma uniforme.
El Principio de Pareto sugiere que en algunos casos, la mayoría de los resultados vienen de la minoría de entradas:
- El 80% de un cierto trozo de software puede ser escrito con el 20% del total de tiempo asignado (a la inversa, el 20% del código más difícil toma el 80% del tiempo).
- El 20% del esfuerzo produce el 80% del resultado
- El 20% del trabajo crea el 80% de los ingresos
- El 20% de los fallos causa el 80% de los problemas
- El 20% de las características se emplean 80% más que el resto
En los años 1940s el ingeniero americano-romaní Dr. Joseph Juran, quien es ampliamente reconocido por atribuírsele ser el padre del control de calidad, [comenzó a aplicar el principio de Pareto a problemas de calidad](https://es.wikipedia.org/wiki/Joseph_Juran).
Este principio es también conocido como: La Regla 80/20, La Ley de los Pocos Vitales y el Principio del Factor de Escasez.
Ejemplos del Mundo-Real:
- En 2002 Microsoft reportó que arreglando el 20% de los errores más reportados, 80% de los errores relacionados y los crashes en Windows y Office habían sido eliminados ([Referencia (en inglés)](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)).
### El Principio de Peter
[El Principio de Peter en Wikipedia](https://es.wikipedia.org/wiki/Principio_de_Peter)
> La gente en una jerarquía tiende a ascender hasta su "nivel de incompetencia".
>
> _Laurence J. Peter_
Un concepto de administración de Laurence J. Peter, el Principio de Peter observa que la gente que es buena en sus trabajos es promocionada hasta llegar a un nivel donde ya no son tan exitosos (su "nivel de incompetencia"). En este punto, como ellos son más _senior_, son menos propensos a ser eliminados de la organización (a menos que su rendimiento sea espectacularmente malo) y continuarán en un rol en el que tienen pocas habilidades intrínsecas. Las habilidades que les hicieron exitosos no son necesariamente las habilidades requeridas para sus nuevos puestos.
Este es de particular interés para los ingenieros - quienes inicialmente comienzan en roles profundamente técnicos, pero a veces tienen una carrera la cual les guía a _administrar_ a otros ingenieros - los cuales requieren un conjunto fundamentalmente diferente de habilidades.
Vea también:
- [El Principio de Dilbert](#el-principio-de-dilbert)
- [La Ley de Putt](#ley-de-putt)
### El Principio de Robustez (Ley de Postel)
[El Principio de Robustez en Wikipedia (inglés)](https://en.wikipedia.org/wiki/Robustness_principle)
> Sé conservador en lo que haces y liberal con lo que recibes de otros.
A veces aplicado en desarrollo de aplicaciones de servidor, este principio establece que lo que tú envias a otros debe ser tan mínimo y consensuado como sea posible, pero lo que deberías tener como objetivo es permitir la entrada no consensuada si es que puede ser procesada.
El objetivo de este principio es construir sistemas los cuales sean robustos, tanto que puedan manejar entradas algo deficientes si aún pueden ser entendidas. Sin embargo, hay potenciales implicaciones de seguridad acerca de aceptar entradas mal formadas, particularmente si el procesamiento de tales entradas no ha sido bien testeado.
### SOLID
Este es un acrónimo el cual se refiere a:
* S: [El Principio de Responsabilidad Única](#principio-de-responsabilidad-unica) (S por _Single Responsability_ del inglés)
* O: [El Principio Abierto/Cerrado](#principio-abierto-cerrado) (O por _Open/Close_)
* L: [El Principio de Sustitución de Liskov](#principio-de-sustitucion-de-liskov) (L por _Liskov_)
* I: [El Principio de Segregación de Interfaces](#principio-de-segregacion-de-interfaces) (I por _Interfaces Segregation_)
* D: [El Principio de Inversión de Dependencia](#principio-de-inversion-de-dependencia)
Estos son los principios clave en la [Programación Orientada a Objetos](#por-hacer). Los principios de diseño tales como estos deben servir de ayuda a desarrolladores para construir sistemas más mantenibles.
### Principio de Responsabilidad Única
[El Principio de Responsabilidad Única en Wikipedia](https://es.wikipedia.org/wiki/Principio_de_responsabilidad_%C3%BAnica)
> Cada módulo o clase debe tener una tan solo una única responsabilidad.
El primero de los principios '[SOLID](#solid)'. Este principio sugiere que los módulos o clases deben hacer una única cosa y solo una. En términos más prácticos, esto quire decir que una único, pequeño cambio a una característica de un programa debe requerir un cambio en un solo componente. Por ejemplo, cambiar como una contraseña es validada por complejidad debe requerir un cambio en solo una parte del programa.
Teóricamente, esto debe hacer el código más robusto (sólido) y fácil de cambiar. Sabiendo que un componente el cual está siendo modificado tiene una única responsabilidad sólo significa que _comprobar_ ese cambio dede ser más fácil. Usando el ejemplo anterior, cambiar el componente de complejidad de la contraseña debe solo afectar a las características relacionadas con la complejidad de la contraseña. Puede ser mucho más difícil tener en cuenta el impacto de un cambio en un componente el cual tiene muchas responsabilidades.
Vea también:
- [Programación Orientada a Objetos](#por-hacer)
- [SOLID](#solid)
### Principio de Abierto/Cerrado
[Principio de Abierto/Cerrado](https://es.wikipedia.org/wiki/Principio_de_abierto/cerrado)
> Las entidades deben estar abiertas para ser extendidas y cerradas para ser modificadas.
El segundo de los principios '[SOLID](#solid). Este principio establece que las entidades (las cuales pueden ser clases, módulos, funciones u otras similares) deben tener la capacidad para ser _extendidas_ (ampliadas), pero de la misma forma debe _existir_ en su comportamiento la capacidad de no ser modificadas.
Como un ejemplo hipotético, imagina un módulo el cual es capaz de convertir un documento Markdown en uno HTML. Si el módulo puede ser ampliado para manejar nuevas características de Markdown, sin modi
gitextract_45dvjnqv/
├── .all-contributorsrc
├── .github/
│ ├── CHANGELOG.md
│ ├── CODE_OF_CONDUCT.md
│ ├── FUNDING.yml
│ ├── contributing.md
│ ├── makefile
│ ├── pull_request_template.md
│ ├── release-please-config.json
│ ├── release-please-manifest.json
│ ├── website/
│ │ ├── backup/
│ │ │ ├── ideas.md
│ │ │ ├── index2.html
│ │ │ ├── index3.html
│ │ │ └── index4.html
│ │ ├── generate.py
│ │ ├── makefile
│ │ ├── requirements.txt
│ │ └── src/
│ │ ├── index.html.jinja
│ │ ├── script.js
│ │ └── styles.css
│ └── workflows/
│ └── cicd.yaml
├── .gitignore
├── LICENSE
├── README.md
├── assets/
│ ├── banner.psd
│ ├── diagrams.bmpr
│ └── site/
│ ├── index.html
│ ├── index2.html
│ ├── index3.html
│ └── index4.html
├── scripts/
│ └── prepare-markdown-for-ebook.sh
└── translations/
├── es-ES.md
├── fr.md
├── id.md
├── it-IT.md
├── jp.md
├── lv.md
├── pl.md
├── pt-BR.md
├── tr.md
└── vi.md
SYMBOL INDEX (6 symbols across 1 files) FILE: .github/website/generate.py function bisect_text (line 11) | def bisect_text(content: str, bisect_line: str) -> tuple[str, str]: function load_template (line 28) | def load_template(): function prepare_markdown (line 34) | def prepare_markdown(path: str) -> str: function parse_markdown (line 46) | def parse_markdown(markdown_content: str): function extract_static_files (line 78) | def extract_static_files(html_content, output_dir): function generate_site (line 119) | def generate_site(markdown_content: str, output_dir: str):
Condensed preview — 40 files, each showing path, character count, and a content snippet. Download the .json file or copy for the full structured content (711K chars).
[
{
"path": ".all-contributorsrc",
"chars": 563,
"preview": "{\n \"files\": [\n \"README.md\"\n ],\n \"imageSize\": 100,\n \"commit\": false,\n \"commitType\": \"docs\",\n \"commitConvention\":"
},
{
"path": ".github/CHANGELOG.md",
"chars": 4782,
"preview": "# Changelog\n\n## [0.5.0](https://github.com/dwmkerr/hacker-laws/compare/v0.4.0...v0.5.0) (2026-02-06)\n\n\n### Features\n\n* a"
},
{
"path": ".github/CODE_OF_CONDUCT.md",
"chars": 3349,
"preview": "# Contributor Covenant Code of Conduct\n\n## Our Pledge\n\nIn the interest of fostering an open and welcoming environment, w"
},
{
"path": ".github/FUNDING.yml",
"chars": 53,
"preview": "# Support 'GitHub Sponsors' funding.\ngithub: dwmkerr\n"
},
{
"path": ".github/contributing.md",
"chars": 6323,
"preview": "# Contributing Guidelines\n\n<!-- vim-markdown-toc GFM -->\n\n- [Goal of the Project](#goal-of-the-project)\n- [Example Law: "
},
{
"path": ".github/makefile",
"chars": 673,
"preview": "default: help\n\n.PHONY: help\nhelp: # Show help for each of the Makefile recipes.\n\t@grep -E '^[a-zA-Z0-9 -]+:.*#' Makefil"
},
{
"path": ".github/pull_request_template.md",
"chars": 847,
"preview": "**Pull Request Checklist**\n\nPlease double check the items below!\n\n- [ ] I have read the [Contributor Guidelines](https:/"
},
{
"path": ".github/release-please-config.json",
"chars": 292,
"preview": "{\n \"release-type\": \"simple\",\n \"bump-minor-pre-major\": true,\n \"packages\": {\n \".\": {\n \"release-type\": \"simple\","
},
{
"path": ".github/release-please-manifest.json",
"chars": 19,
"preview": "{\n \".\": \"0.5.0\"\n}\n"
},
{
"path": ".github/website/backup/ideas.md",
"chars": 0,
"preview": ""
},
{
"path": ".github/website/backup/index2.html",
"chars": 7287,
"preview": "<!DOCTYPE html>\n<html lang=\"en\">\n<head>\n <meta charset=\"UTF-8\" />\n <meta name=\"viewport\" content=\"width=device-width, "
},
{
"path": ".github/website/backup/index3.html",
"chars": 7382,
"preview": "<!DOCTYPE html>\n<html lang=\"en\">\n<head>\n <meta charset=\"UTF-8\" />\n <meta name=\"viewport\" content=\"width=device-width, "
},
{
"path": ".github/website/backup/index4.html",
"chars": 0,
"preview": ""
},
{
"path": ".github/website/generate.py",
"chars": 5265,
"preview": "\"\"\"Generate the Hacker Laws website from the Hacker Laws README\"\"\"\n\nimport argparse\nimport os\nimport shutil\nfrom jinja2 "
},
{
"path": ".github/website/makefile",
"chars": 1170,
"preview": "SHELL := /bin/bash\nTEMPLATE_DIR=src\nTEMPLATE_FILE=index.html.jinja\nMARKDOWN_FILE=../../README.md\nOUTPUT_FILE=build/index"
},
{
"path": ".github/website/requirements.txt",
"chars": 40,
"preview": "markdown\njinja2\nwatchdog\nbeautifulsoup4\n"
},
{
"path": ".github/website/src/index.html.jinja",
"chars": 3499,
"preview": "<!DOCTYPE html>\n<html lang=\"en\">\n <head>\n <meta charset=\"UTF-8\" />\n <meta name=\"viewport\" content=\"width=device-w"
},
{
"path": ".github/website/src/script.js",
"chars": 685,
"preview": "$(document).ready(function() {\n $(\"h1, h2, h3, h4, h5, h6\").each(function() {\n var $heading = $(this);\n "
},
{
"path": ".github/website/src/styles.css",
"chars": 1467,
"preview": "html {\n scroll-behavior: auto !important;\n}\n\nbody {\n font-family: 'Inter', sans-serif;\n background-color: #fff;\n c"
},
{
"path": ".github/workflows/cicd.yaml",
"chars": 3020,
"preview": "name: CI/CD\n\non:\n push:\n branches: [main]\n pull_request:\n workflow_dispatch:\n\n# Permissions to check contents and "
},
{
"path": ".gitignore",
"chars": 10,
"preview": ".DS_Store\n"
},
{
"path": "LICENSE",
"chars": 18588,
"preview": "Copyright (c) Dave Kerr 2021\n\n# Attribution-ShareAlike 4.0 International\n\nCreative Commons Corporation (“Creative Common"
},
{
"path": "README.md",
"chars": 75790,
"preview": "<h1 align=\"center\"><a href=\"https://hacker-laws.com\" target=\"_blank\">hacker-laws</a></h1>\n<h4 align=\"center\">🧠 Laws, The"
},
{
"path": "assets/site/index.html",
"chars": 3729,
"preview": "<!DOCTYPE html>\n<html lang=\"en\">\n<head>\n <meta charset=\"UTF-8\">\n <title>Interactive Hacker Laws Stack</title>\n <style"
},
{
"path": "assets/site/index2.html",
"chars": 3502,
"preview": "\n<!DOCTYPE html>\n<html lang=\"en\">\n<head>\n <meta charset=\"UTF-8\">\n <title>Interactive Hacker Laws Stack</title>\n <styl"
},
{
"path": "assets/site/index3.html",
"chars": 4030,
"preview": "<!DOCTYPE html>\n<html lang=\"en\">\n<head>\n <meta charset=\"UTF-8\">\n <title>Interactive Hacker Laws Stack</title>\n <style"
},
{
"path": "assets/site/index4.html",
"chars": 5672,
"preview": "<!--\nInteractive Hacker Laws Stack - Specification:\n\n1. User Experience:\n - Display a vertically scrolling list of ite"
},
{
"path": "scripts/prepare-markdown-for-ebook.sh",
"chars": 1333,
"preview": "#!/usr/bin/env bash\n\n# Fail on errors.\nset -e -o pipefail\n\n# Check if parameters are provided\ninput=\"$1\"\noutput=\"$2\"\nif "
},
{
"path": "translations/es-ES.md",
"chars": 46745,
"preview": "# 💻📖 hacker-laws\n\nLeyes, Teorías, Principios y Patrones que los desarrolladores encontrarán útiles.\n\n[traducciones](#tra"
},
{
"path": "translations/fr.md",
"chars": 55470,
"preview": "# 💻📖 hacker-laws\n\nLois, théories, principes et modèles que les développeurs trouveront utiles.\n\n[Traductions](#translati"
},
{
"path": "translations/id.md",
"chars": 50791,
"preview": "# 💻📖 Undang Undang Peretas\n\n[](https://gitloca"
},
{
"path": "translations/it-IT.md",
"chars": 38306,
"preview": "# 💻📖 hacker-laws\n\nLeggi, teorie, principi e pattern utili agli sviluppatori.\n\n[traduzioni](#translations): [🇧🇷](./transl"
},
{
"path": "translations/jp.md",
"chars": 33530,
"preview": "# 💻📖 ハッカーの法則\n\n開発者が役に立つと思う法則、理論、原則、パターン。\n\n[翻訳](#翻訳): [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-la"
},
{
"path": "translations/lv.md",
"chars": 46616,
"preview": "# 💻📖 hacker-laws\n\n[](https://gitlocalize.com/r"
},
{
"path": "translations/pl.md",
"chars": 73513,
"preview": "# 💻📖 prawa-hakerskie\n\nPrawa, teorie, zasady i wzorce, które programiści uznają za przydatne.\n\n[Tłumaczenia](#translation"
},
{
"path": "translations/pt-BR.md",
"chars": 53157,
"preview": "# 💻📖 hacker-laws\n\nLeis, teorias, princípios e padrões que desenvolvedores acharão úteis.\n\n[Traduções](#translations): [🇨"
},
{
"path": "translations/tr.md",
"chars": 62103,
"preview": "# 💻📖 hacker-laws\n\nProgramcıların faydalı bulacağı yasalar, teoriler, prensipler ve desenler.\n\n[Çeviriler](#%C3%A7evirile"
},
{
"path": "translations/vi.md",
"chars": 76174,
"preview": "# 💻📖 luật của hacker\n\nCác Luật, Lý thuyết, Nguyên tắc và Mẫu sẽ hữu ích cho các nhà phát triển phần mềm.\n\n[Bản dịch](#tr"
}
]
// ... and 2 more files (download for full content)
About this extraction
This page contains the full source code of the dwmkerr/hacker-laws GitHub repository, extracted and formatted as plain text for AI agents and large language models (LLMs). The extraction includes 40 files (679.5 KB), approximately 199.2k tokens, and a symbol index with 6 extracted functions, classes, methods, constants, and types. Use this with OpenClaw, Claude, ChatGPT, Cursor, Windsurf, or any other AI tool that accepts text input. You can copy the full output to your clipboard or download it as a .txt file.
Extracted by GitExtract — free GitHub repo to text converter for AI. Built by Nikandr Surkov.