Merge pull request #447 from dwmkerr/release-please--branches--main

chore(main): release 0.3.1

.github/CHANGELOG.md

@@ -0,0 +1,48 @@
+# Changelog
+
+## [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))

.github/contributing.md

@@ -2,11 +2,18 @@
 
 <!-- vim-markdown-toc GFM -->
 
-* [Example Law: The Law of Leaky Abstractions](#example-law-the-law-of-leaky-abstractions)
+- [Goal of the Project](#goal-of-the-project)
-* [Localisation](#localisation)
+- [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.
@@ -30,7 +37,7 @@ An example law is shown below, which covers most of the key points:
 
 ---
 
-### Example Law: The Law of Leaky Abstractions
+## 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/)
 
@@ -54,10 +61,45 @@ 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.
 
-### Localisation
+## 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:
 
 ![GitLocalize Screenshot](../images/gitlocalize.png)
 
-This is still work in progress - if you would like to be a maintainer for a language just open an issue to get in touch!
+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"

.github/makefile

@@ -0,0 +1,22 @@
+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

.github/pull_request_template.md

@@ -2,7 +2,7 @@
 
 Please double check the items below!
 
-- [ ] I have read the [Contributor Guidelines](./.github/contributing.md).
+- [ ] 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).

.github/release-please-config.json

@@ -0,0 +1,18 @@
+{
+  "release-type": "simple",
+  "bump-minor-pre-major": true,
+  "packages": {
+    ".": {
+      "release-type": "simple",
+      "extra-files": [
+        {
+          "type": "generic",
+          "path": "README.md"
+        }
+      ],
+     "changelog-path": ".github/CHANGELOG.md"
+    }
+  }
+}
+
+

.github/release-please-manifest.json

@@ -0,0 +1,3 @@
+{
+  ".": "0.3.1"
+}

.github/website/backup/index2.html

@@ -0,0 +1,189 @@
+<!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>&copy; 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>
+

.github/website/backup/index3.html

@@ -0,0 +1,194 @@
+<!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>&copy; 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>
+

.github/website/build/.gitignore

@@ -0,0 +1 @@
+*

.github/website/generate.py

@@ -0,0 +1,161 @@
+"""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)

.github/website/makefile

@@ -0,0 +1,38 @@
+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)

.github/website/requirements.txt

@@ -0,0 +1,4 @@
+markdown
+jinja2
+watchdog
+beautifulsoup4

.github/website/src/favicon.svg

@@ -0,0 +1,3 @@
+<svg width="32" height="32" viewBox="0 0 32 32" fill="none" xmlns="http://www.w3.org/2000/svg">
+<path fill-rule="evenodd" clip-rule="evenodd" d="M16 0C7.16 0 0 7.16 0 16C0 23.08 4.58 29.06 10.94 31.18C11.74 31.32 12.04 30.84 12.04 30.42C12.04 30.04 12.02 28.78 12.02 27.44C8 28.18 6.96 26.46 6.64 25.56C6.46 25.1 5.68 23.68 5 23.3C4.44 23 3.64 22.26 4.98 22.24C6.24 22.22 7.14 23.4 7.44 23.88C8.88 26.3 11.18 25.62 12.1 25.2C12.24 24.16 12.66 23.46 13.12 23.06C9.56 22.66 5.84 21.28 5.84 15.16C5.84 13.42 6.46 11.98 7.48 10.86C7.32 10.46 6.76 8.82 7.64 6.62C7.64 6.62 8.98 6.2 12.04 8.26C13.32 7.9 14.68 7.72 16.04 7.72C17.4 7.72 18.76 7.9 20.04 8.26C23.1 6.18 24.44 6.62 24.44 6.62C25.32 8.82 24.76 10.46 24.6 10.86C25.62 11.98 26.24 13.4 26.24 15.16C26.24 21.3 22.5 22.66 18.94 23.06C19.52 23.56 20.02 24.52 20.02 26.02C20.02 28.16 20 29.88 20 30.42C20 30.84 20.3 31.34 21.1 31.18C27.42 29.06 32 23.06 32 16C32 7.16 24.84 0 16 0V0Z" fill="#24292E"/>
+</svg>

.github/website/src/index.html.jinja

@@ -0,0 +1,76 @@
+<!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/&num;{{ 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>&copy; 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>

.github/website/src/script.js

@@ -0,0 +1,21 @@
+$(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');
+});

.github/website/src/styles.css

@@ -0,0 +1,80 @@
+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;
+}

.github/workflows/cicd.yaml

@@ -0,0 +1,108 @@
+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
+    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

LICENSE

@@ -1,4 +1,4 @@
-Copyright (c) Dave Kerr 2019
+Copyright (c) Dave Kerr 2021
 
 # Attribution-ShareAlike 4.0 International
 

README.md

@@ -1,69 +1,93 @@
-# 💻📖 hacker-laws
+<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>
 
-Laws, Theories, Principles and Patterns that developers will find useful.
+---
 
-- 🇨🇳 [中文 / Chinese Version](https://github.com/nusr/hacker-laws-zh) - thanks [Steve Xu](https://github.com/nusr)!
+- 📖 My new book [Effective Shell (Online Version)](https://effective-shell.com) on [Amazon (Print/Kindle)](https://amzn.to/4ho0F91)
-- 🇮🇹 [Traduzione in Italiano](https://github.com/csparpa/hacker-laws-it) - grazie [Claudio Sparpaglione](https://github.com/csparpa)!
+- 🌍 Try [hacker-laws.com](https://hacker-laws.com)
-- 🇰🇷 [한국어 / Korean Version](https://github.com/codeanddonuts/hacker-laws-kr) - thanks [Doughnut](https://github.com/codeanddonuts)!
+- 🧠 Check out my new project [Terminal AI](https://github.com/dwmkerr/terminal-ai)
-- 🇷🇺 [Русская версия / Russian Version](https://github.com/solarrust/hacker-laws) - thanks [Alena Batitskaya](https://github.com/solarrust)!
+- ☕️ Like this project? Consider [buying me a coffee with a one-off donation](https://github.com/sponsors/dwmkerr?frequency=one-time)
-- 🇹🇷 [Türkçe / Turkish Version](https://github.com/umutphp/hacker-laws-tr) - thanks [Umut Işık](https://github.com/umutphp)
+- 🎧 Listen to the podcast [The Changelog - Laws for Hackers to Live By](https://changelog.com/podcast/403)
-- 🇧🇷 [Brasileiro / Brazilian Version](./translations/pt-BR.md) - thanks [Leonardo Costa](https://github.com/LeoFC97)
+- 📖 Download the [PDF eBook](https://github.com/dwmkerr/hacker-laws/releases/latest/download/hacker-laws.pd)
-- 🇪🇸 [Castellano / Spanish Version](./translations/es-ES.md) - thanks [Manuel Rubio](https://github.com/manuel-rubio)
+- 🌏 See the [Translations](#translations)
-
-Like this project? Please considering [Sponsoring Me](https://github.com/sponsors/dwmkerr)!
 
 ---
 
 <!-- vim-markdown-toc GFM -->
 
-* [Introduction](#introduction)
+- [Introduction](#introduction)
-* [Laws](#laws)
+- [Laws](#laws)
-    * [Amdahl's Law](#amdahls-law)
+    - [90–9–1 Principle (1% Rule)](#9091-principle-1-rule)
-    * [The Broken Windows Theory](#the-broken-windows-theory)
+    - [90–90 Rule](#9090-rule)
-    * [Brooks' Law](#brooks-law)
+    - [Amdahl's Law](#amdahls-law)
-    * [Conway's Law](#conways-law)
+    - [The Broken Windows Theory](#the-broken-windows-theory)
-    * [Cunningham's Law](#cunninghams-law)
+    - [Brooks' Law](#brooks-law)
-    * [Dunbar's Number](#dunbars-number)
+    - [CAP Theorem (Brewer's Theorem)](#cap-theorem-brewers-theorem)
-    * [Gall's Law](#galls-law)
+    - [Clarke's three laws](#clarkes-three-laws)
-    * [Goodhart's Law](#goodharts-law)
+    - [Conway's Law](#conways-law)
-    * [Hanlon's Razor](#hanlons-razor)
+    - [Cunningham's Law](#cunninghams-law)
-    * [Hofstadter's Law](#hofstadters-law)
+    - [Dunbar's Number](#dunbars-number)
-    * [Hutber's Law](#hutbers-law)
+    - [The Dunning-Kruger Effect](#the-dunning-kruger-effect)
-    * [The Hype Cycle & Amara's Law](#the-hype-cycle--amaras-law)
+    - [Fitts' Law](#fitts-law)
-    * [Hyrum's Law (The Law of Implicit Interfaces)](#hyrums-law-the-law-of-implicit-interfaces)
+    - [Gall's Law](#galls-law)
-    * [Metcalfe's Law](#metcalfes-law)
+    - [Goodhart's Law](#goodharts-law)
-    * [Moore's Law](#moores-law)
+    - [Hanlon's Razor](#hanlons-razor)
-    * [Murphy's Law / Sod's Law](#murphys-law--sods-law)
+    - [Hick's Law (Hick-Hyman Law)](#hicks-law-hick-hyman-law)
-    * [Occam's Razor](#occams-razor)
+    - [Hofstadter's Law](#hofstadters-law)
-    * [Parkinson's Law](#parkinsons-law)
+    - [Hutber's Law](#hutbers-law)
-    * [Premature Optimization Effect](#premature-optimization-effect)
+    - [The Hype Cycle & Amara's Law](#the-hype-cycle--amaras-law)
-    * [Putt's Law](#putts-law)
+    - [Hyrum's Law (The Law of Implicit Interfaces)](#hyrums-law-the-law-of-implicit-interfaces)
-    * [Reed's Law](#reeds-law)
+    - [Input-Process-Output (IPO)](#input-process-output-ipo)
-    * [The Law of Conservation of Complexity (Tesler's Law)](#the-law-of-conservation-of-complexity-teslers-law)
+    - [Kernighan's Law](#kernighans-law)
-    * [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
+    - [Koomey's Law](#koomeys-law)
-    * [The Law of Triviality](#the-law-of-triviality)
+    - [Linus's Law](#linuss-law)
-    * [The Unix Philosophy](#the-unix-philosophy)
+    - [Metcalfe's Law](#metcalfes-law)
-    * [The Spotify Model](#the-spotify-model)
+    - [Moore's Law](#moores-law)
-    * [Wadler's Law](#wadlers-law)
+    - [Murphy's Law / Sod's Law](#murphys-law--sods-law)
-    * [Wheaton's Law](#wheatons-law)
+    - [Occam's Razor](#occams-razor)
-* [Principles](#principles)
+    - [Parkinson's Law](#parkinsons-law)
-    * [The Dilbert Principle](#the-dilbert-principle)
+    - [Premature Optimization Effect](#premature-optimization-effect)
-    * [The Pareto Principle (The 80/20 Rule)](#the-pareto-principle-the-8020-rule)
+    - [Putt's Law](#putts-law)
-    * [The Peter Principle](#the-peter-principle)
+    - [Reed's Law](#reeds-law)
-    * [The Robustness Principle (Postel's Law)](#the-robustness-principle-postels-law)
+    - [The Bitter Lesson](#the-bitter-lesson)
-    * [SOLID](#solid)
+    - [The Ringelmann Effect](#the-ringelmann-effect)
-    * [The Single Responsibility Principle](#the-single-responsibility-principle)
+    - [The Law of Conservation of Complexity (Tesler's Law)](#the-law-of-conservation-of-complexity-teslers-law)
-    * [The Open/Closed Principle](#the-openclosed-principle)
+    - [The Law of Demeter](#the-law-of-demeter)
-    * [The Liskov Substitution Principle](#the-liskov-substitution-principle)
+    - [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
-    * [The Interface Segregation Principle](#the-interface-segregation-principle)
+    - [The Law of the Instrument](#the-law-of-the-instrument)
-    * [The Dependency Inversion Principle](#the-dependency-inversion-principle)
+    - [The Law of Triviality](#the-law-of-triviality)
-    * [The DRY Principle](#the-dry-principle)
+    - [The Unix Philosophy](#the-unix-philosophy)
-    * [The KISS principle](#the-kiss-principle)
+    - [The Scout Rule](#the-scout-rule)
-    * [YAGNI](#yagni)
+    - [The Spotify Model](#the-spotify-model)
-    * [The Fallacies of Distributed Computing](#the-fallacies-of-distributed-computing)
+    - [The Two Pizza Rule](#the-two-pizza-rule)
-* [Reading List](#reading-list)
+    - [Twyman's law](#twymans-law)
-* [Contributing](#contributing)
+    - [Wadler's Law](#wadlers-law)
-* [TODO](#todo)
+    - [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 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)
 
 <!-- vim-markdown-toc -->
 
@@ -71,11 +95,38 @@ Like this project? Please considering [Sponsoring Me](https://github.com/sponsor
 
 There are lots of laws which people discuss when talking about development. This repository is a reference and overview of some of the most common ones. Please share and submit PRs!
 
-❗: This 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.
+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
 
-And here we go!
+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
 
@@ -89,7 +140,6 @@ The diagram below shows some examples of potential improvements in speed:
 
 <img width="480px" alt="Diagram: Amdahl's Law" src="./images/amdahls_law.png" />
 
-*(Image Reference: By Daniels220 at English Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)*
 
 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.
 
@@ -114,7 +164,7 @@ See also:
 
 Examples:
 
-- [The Pragmatic Programming: Software Entropy](https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy)
+- [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/)
 
@@ -124,7 +174,7 @@ Examples:
 
 > 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.
+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.
 
@@ -135,11 +185,47 @@ 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 orientated around features or services, the software systems will also reflect this.
+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:
 
@@ -163,12 +249,47 @@ See also:
 
 "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.
+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)
@@ -179,7 +300,7 @@ See also:
 
 Gall's Law implies that attempts to _design_ highly complex systems are likely to fail. Highly complex systems are rarely built in one go, but evolve instead from more simple systems.
 
-The classic example is the world-wide-web. In it's current state, it is a highly complex system. However, it was defined initially as a simple way to share content between academic institutions. It was very successful in meeting these goals and evolved to become more complex over time.
+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:
 
@@ -202,7 +323,7 @@ Also commonly referenced as:
 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 metric intent was to create well-tested software.
+- 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:
@@ -219,6 +340,28 @@ See also:
 
 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.
+
+![Hicks law](./images/hicks_law.svg)
+
+
+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)
@@ -259,7 +402,6 @@ The Hype Cycle is a visual representation of the excitement and development of t
 
 ![The Hype Cycle](./images/gartner_hype_cycle.png)
 
-*(Image Reference: By Jeremykemp at English Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)*
 
 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".
 
@@ -274,13 +416,82 @@ In short, this cycle suggests that there is typically a burst of excitement arou
 >
 > (Hyrum Wright)
 
-Hyrum's Law states that when you have a _large enough number of consumers_ of an API, all behaviours of the API (even those not defined as part of a public contract) will eventually come to be depended on by someone. A trivial example may be non-functional elements such as the response time of an API. A more subtle example might be consumers who are relying on applying a regex to an error message to determine the *type* of error of an API. Even if the public contract of the API states nothing about the contents of the message, indicating users should use an associated error code, _some_ users may use the message, and changing the message essentially breaks the API for those users.
 
 See also:
 
 - [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
 - [XKCD 1172](https://xkcd.com/1172/)
 
+### 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
 
@@ -302,6 +513,10 @@ See also:
 
 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)
@@ -348,7 +563,6 @@ Example:
 
 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.
 
-If this law were combined with [Hofstadter's Law](#hofstadters-law), an even more pessimistic viewpoint is reached - work will expand to fill the time available for its completion and *still take longer than expected*.
 
 See also:
 
@@ -356,13 +570,12 @@ See also:
 
 ### Premature Optimization Effect
 
-[Premature Optimization on WikiWikiWeb](http://wiki.c2.com/?PrematureOptimization)
+[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)
 
-In Donald Knuth's paper [Structured Programming With Go To Statements](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements), he wrote: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: **premature optimization is the root of all evil**. Yet we should not pass up our opportunities in that critical 3%."
 
 However, _Premature Optimization_ can be defined (in less loaded terms) as optimizing before we know that we need to.
 
@@ -385,7 +598,6 @@ 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)
@@ -398,6 +610,27 @@ 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)
@@ -408,6 +641,18 @@ Some complexity in a system is 'inadvertent'. It is a consequence of poor struct
 
 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/)
@@ -418,7 +663,6 @@ One interesting element to this law is the suggestion that even by simplifying t
 
 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.
 
@@ -432,6 +676,25 @@ 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)
@@ -440,7 +703,7 @@ This law suggests that groups will give far more time and attention to trivial o
 
 The common fictional example used is that of a committee approving plans for nuclear power plant, who spend the majority of their time discussing the structure of the bike shed, rather than the far more important design for the power plant itself. It can be difficult to give valuable input on discussions about very large, complex topics without a high degree of subject matter expertise or preparation. However, people want to be seen to be contributing valuable input. Hence a tendency to focus too much time on small details, which can be reasoned about easily, but are not necessarily of particular importance.
 
-The fictional example above led to the usage of the term 'Bike Shedding' as an expression for wasting time on trivial details. An alternative term is 'Yak Shaving'.
+The 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
 
@@ -450,6 +713,26 @@ The Unix Philosophy is that software components should be small, and focused on
 
 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/)
@@ -458,6 +741,32 @@ The Spotify Model is an approach to team and organisation structure which has be
 
 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)
@@ -493,6 +802,60 @@ Coined by Wil Wheaton (Star Trek: The Next Generation, The Big Bang Theory), thi
 
 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)
@@ -524,12 +887,31 @@ The Pareto Principle suggests that in some cases, the majority of results come f
 
 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.
+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 Peter Principle
 
 [The Peter Principle on Wikipedia](https://en.wikipedia.org/wiki/Peter_principle)
@@ -538,9 +920,9 @@ Real-world examples:
 >
 > _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.
+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 initial start out in deeply technical roles, but often have a career path which leads to _managing_ other engineers - which requires a fundamentally different skills-set.
+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:
 
@@ -553,19 +935,20 @@ See Also:
 
 > Be conservative in what you do, be liberal in what you accept from others.
 
-Often applied in server application development, this principle states that what you send to others should be as minimal and conformant as possible, but you should be aim to allow non-conformant input if it can be processed.
+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.
+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:
 
-* S: [The Single Responsibility Principle](#the-single-responsibility-principle)
-* O: [The Open/Closed Principle](#the-openclosed-principle)
-* L: [The Liskov Substitution Principle](#the-liskov-substitution-principle)
-* I: [The Interface Segregation Principle](#the-interface-segregation-principle)
-* D: [The Dependency Inversion Principle](#the-dependency-inversion-principle)
 
 These are key principles in [Object-Oriented Programming](#todo). Design principles such as these should be able to aid developers build more maintainable systems.
 
@@ -577,7 +960,7 @@ These are key principles in [Object-Oriented Programming](#todo). Design princip
 
 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 which is 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.
+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:
 
@@ -592,7 +975,7 @@ See also:
 
 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. If the module could be extended to handle a newly proposed markdown feature, without modifying the module internals, then it would be open for extension. If the module could _not_ be modified by a consumer so that how existing Markdown features are handled, then it would be _closed_ for modification.
+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.
 
@@ -609,7 +992,7 @@ See also:
 
 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 able to be used in the function. If 'file' supports seeking in reverse, and the XML parser uses that function, but the derived type 'network file' fails when reverse seeking is attempted, then the 'network file' would be violating the principle.
+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.
 
@@ -643,7 +1026,7 @@ See also:
 
 > 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.
+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.
 
@@ -662,7 +1045,7 @@ See also:
 
 > 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 Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+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).
 
@@ -670,7 +1053,7 @@ In practice, if you have the same piece of information in two (or more) differen
 
 See also:
 
-- [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+- [The Pragmatic Programmer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
 
 ### The KISS principle
 
@@ -690,7 +1073,6 @@ See also:
 
 [YAGNI on Wikipedia](https://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it)
 
-This is an acronym for _**Y**ou **A**in't **G**onna **N**eed **I**t_.
 
 > Always implement things when you actually need them, never when you just foresee that you need them.
 >
@@ -706,7 +1088,7 @@ See also:
 
 ### The Fallacies of Distributed Computing
 
-[The Fallacies of Distributed Computing on Wikipedia](https://en.wikipedia.org/wiki/You_aren%https://en.wikipedia.org/wiki/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:
 
@@ -721,7 +1103,7 @@ Also known as _Fallacies of Networked Computing_, the Fallacies are a list of co
 
 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 were inspired by what was happening at the time inside [Sun Microsystems](https://en.wikipedia.org/wiki/Sun_Microsystems).
+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.
 
@@ -729,26 +1111,51 @@ 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)
-- [Deutsch's Fallacies, 10 Years After](http://java.sys-con.com/node/38665)
+
+### 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.
-- [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.
 - [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).
 
-## Contributing
+## Online Resources
 
-Please do contribute! [Raise an issue](https://github.com/dwmkerr/hacker-laws/issues/new) if you'd like to suggest an addition or change, or [Open a pull request](https://github.com/dwmkerr/hacker-laws/compare) to propose your own changes.
+Some useful resources and reading.
 
-Please be sure to read the [Contributing Guidelines](./.github/contributing.md) for requirements on text, style and so on. Please be aware of the [Code of Conduct](./.github/CODE_OF_CONDUCT.md) when engaging in discussions on the project.
+- [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.
 
-## TODO
+## PDF eBook
 
-Hi! If you land here, you've clicked on a link to a topic I've not written up yet, sorry about this - this is work in progress!
+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>
 
-Feel free to [Raise an Issue](https://github.com/dwmkerr/hacker-laws/issues) requesting more details, or [Open a Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) to submit your proposed definition of the topic.

assets/sharing.md

@@ -1,20 +0,0 @@
-# Sharing
-
-Copy paste the below for sharing on social media. The channels are:
-
-- [Hacker News](https://news.ycombinator.com)
-- [`r/programming`](https://reddit.com/r/programming/)
-- LinkedIn
-- Twitter
-
-## LinkedIn
-
-#hackerlaws - <Law Name> - <Short Quote>
-
-<Link>
-
-Hacker Laws is a set of theories, principles and patterns that developers will find useful.
-
-Thanks <person>
-
-#hacking #programming #coding #development #computerscience #logic

assets/site/index.html

@@ -0,0 +1,119 @@
+<!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>
+

assets/site/index2.html

@@ -0,0 +1,110 @@
+
+<!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>
+

assets/site/index3.html

@@ -0,0 +1,127 @@
+<!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>
+

assets/site/index4.html

@@ -0,0 +1,158 @@
+<!--
+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>
+

images/Fitts_Law.svg

@@ -0,0 +1,363 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<svg
+   width="640"
+   height="480"
+   version="1.1"
+   id="svg195"
+   sodipodi:docname="Fitts_Law.svg"
+   inkscape:version="1.1 (c68e22c387, 2021-05-23)"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:svg="http://www.w3.org/2000/svg">
+  <defs
+     id="defs199" />
+  <sodipodi:namedview
+     id="namedview197"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageshadow="2"
+     inkscape:pageopacity="0.0"
+     inkscape:pagecheckerboard="0"
+     showgrid="false"
+     inkscape:zoom="1.2197592"
+     inkscape:cx="253.73861"
+     inkscape:cy="240.21135"
+     inkscape:window-width="1920"
+     inkscape:window-height="1043"
+     inkscape:window-x="0"
+     inkscape:window-y="0"
+     inkscape:window-maximized="1"
+     inkscape:current-layer="layer2" />
+  <g
+     inkscape:groupmode="layer"
+     id="layer2"
+     inkscape:label="Layer 2"
+     style="display:inline">
+    <rect
+       style="fill:#ffffff;stroke-width:0"
+       id="rect557"
+       width="100%"
+       height="100%"
+       x="0"
+       y="0" />
+  </g>
+  <!-- Created with SVG-edit - http://svg-edit.googlecode.com/ -->
+  <g
+     id="g193">
+    <title
+       id="title161">Layer 1</title>
+    <g
+       id="svg_14"
+       transform="rotate(38.2092, 97, 276.029)">
+      <line
+         stroke-linecap="round"
+         id="svg_10"
+         y2="276"
+         x2="92"
+         y1="301"
+         x1="92.000002"
+         stroke-width="4"
+         stroke="#000000"
+         fill="none" />
+      <line
+         stroke-linecap="round"
+         id="svg_7"
+         y2="281"
+         x2="112"
+         y1="276"
+         x1="102"
+         stroke-width="4"
+         stroke="#000000"
+         fill="none" />
+      <line
+         id="svg_8"
+         stroke-linecap="round"
+         y2="276"
+         x2="102"
+         y1="301.058297"
+         x1="102"
+         stroke-width="4"
+         stroke="#000000"
+         fill="none" />
+      <line
+         id="svg_11"
+         stroke-linecap="round"
+         y2="276"
+         x2="92"
+         y1="281"
+         x1="82"
+         stroke-width="4"
+         stroke="#000000"
+         fill="none" />
+      <line
+         id="svg_12"
+         y2="251"
+         x2="97"
+         y1="281"
+         x1="82"
+         stroke-linecap="round"
+         stroke-linejoin="null"
+         stroke-dasharray="null"
+         stroke-width="4"
+         stroke="#000000"
+         fill="none" />
+      <line
+         id="svg_13"
+         y2="251"
+         x2="97"
+         y1="281"
+         x1="112"
+         stroke-linecap="round"
+         stroke-linejoin="null"
+         stroke-dasharray="null"
+         stroke-width="4"
+         stroke="#000000"
+         fill="none" />
+    </g>
+    <g
+       id="svg_16">
+      <line
+         fill="none"
+         stroke="#7f7f7f"
+         stroke-width="2"
+         stroke-linejoin="round"
+         stroke-linecap="round"
+         x1="570"
+         y1="135"
+         x2="420"
+         y2="135"
+         id="svg_1"
+         stroke-dasharray="5,5" />
+      <line
+         fill="none"
+         stroke="#7f7f7f"
+         stroke-width="2"
+         stroke-linejoin="round"
+         stroke-linecap="round"
+         x1="495"
+         y1="210"
+         x2="495"
+         y2="60"
+         id="svg_4"
+         stroke-dasharray="5,5" />
+      <rect
+         fill="none"
+         stroke="#000000"
+         stroke-width="5"
+         stroke-linejoin="round"
+         stroke-linecap="round"
+         x="445"
+         y="85"
+         width="100"
+         height="100"
+         id="svg_2" />
+      <text
+         fill="#000000"
+         stroke="#000000"
+         stroke-width="0"
+         stroke-dasharray="null"
+         stroke-linejoin="round"
+         stroke-linecap="round"
+         x="495.91669"
+         y="118.66669"
+         id="svg_3"
+         font-size="24"
+         font-family="Sans-serif"
+         text-anchor="middle"
+         xml:space="preserve"
+         font-weight="bold">Target</text>
+    </g>
+    <text
+       font-weight="bold"
+       xml:space="preserve"
+       text-anchor="middle"
+       font-family="Sans-serif"
+       font-size="24"
+       id="svg_5"
+       y="35"
+       x="494"
+       stroke-linecap="round"
+       stroke-linejoin="null"
+       stroke-dasharray="5,5"
+       stroke-width="0"
+       stroke="#7f7f7f"
+       fill="#000000">W</text>
+    <g
+       id="svg_21">
+      <line
+         fill="none"
+         stroke="#000000"
+         stroke-width="3"
+         stroke-linejoin="null"
+         stroke-linecap="round"
+         x1="445"
+         y1="45"
+         x2="545"
+         y2="45"
+         id="svg_9" />
+      <line
+         id="svg_17"
+         y2="55"
+         x2="455"
+         y1="45"
+         x1="445"
+         stroke-linecap="round"
+         stroke-linejoin="null"
+         stroke-width="3"
+         stroke="#000000"
+         fill="none" />
+      <line
+         id="svg_18"
+         y2="35"
+         x2="455"
+         y1="45"
+         x1="445"
+         stroke-linecap="round"
+         stroke-linejoin="null"
+         stroke-width="3"
+         stroke="#000000"
+         fill="none" />
+      <line
+         id="svg_19"
+         y2="55"
+         x2="535"
+         y1="45"
+         x1="545"
+         stroke-linecap="round"
+         stroke-linejoin="null"
+         stroke-width="3"
+         stroke="#000000"
+         fill="none" />
+      <line
+         id="svg_20"
+         y2="35"
+         x2="535"
+         y1="45"
+         x1="545"
+         stroke-linecap="round"
+         stroke-linejoin="null"
+         stroke-width="3"
+         stroke="#000000"
+         fill="none" />
+    </g>
+    <g
+       id="svg_37"
+       transform="rotate(-17.3352, 328.667, 273.333)">
+      <line
+         fill="none"
+         stroke="#7f7f7f"
+         stroke-width="2"
+         stroke-dasharray="5,5"
+         stroke-linejoin="null"
+         stroke-linecap="round"
+         x1="128.666668"
+         y1="191.333333"
+         x2="528.666668"
+         y2="191.333333"
+         id="svg_6" />
+      <text
+         id="svg_15"
+         font-weight="bold"
+         xml:space="preserve"
+         text-anchor="middle"
+         font-family="Sans-serif"
+         font-size="24"
+         y="349.333338"
+         x="327.000016"
+         stroke-linecap="round"
+         stroke-linejoin="null"
+         stroke-dasharray="5,5"
+         stroke-width="0"
+         stroke="#7f7f7f"
+         fill="#000000">D</text>
+      <g
+         id="svg_34">
+        <line
+           fill="none"
+           stroke="#000000"
+           stroke-width="3"
+           stroke-linejoin="null"
+           stroke-linecap="round"
+           x1="128.666668"
+           y1="316.000005"
+           x2="528.666668"
+           y2="316.000005"
+           id="svg_29" />
+        <line
+           y2="326.000005"
+           x2="138.666668"
+           y1="316.000005"
+           x1="128.666668"
+           stroke-linecap="round"
+           stroke-linejoin="null"
+           stroke-width="3"
+           stroke="#000000"
+           fill="none"
+           id="svg_30" />
+        <line
+           y2="306.000005"
+           x2="138.666668"
+           y1="316.000005"
+           x1="128.666668"
+           stroke-linecap="round"
+           stroke-linejoin="null"
+           stroke-width="3"
+           stroke="#000000"
+           fill="none"
+           id="svg_31" />
+        <line
+           y2="326.000005"
+           x2="518.666668"
+           y1="316.000005"
+           x1="528.666668"
+           stroke-linecap="round"
+           stroke-linejoin="null"
+           stroke-width="3"
+           stroke="#000000"
+           fill="none"
+           id="svg_32" />
+        <line
+           y2="306.000005"
+           x2="518.666668"
+           y1="316.000005"
+           x1="528.666668"
+           stroke-linecap="round"
+           stroke-linejoin="null"
+           stroke-width="3"
+           stroke="#000000"
+           fill="none"
+           id="svg_33" />
+      </g>
+      <line
+         fill="none"
+         stroke="#7f7f7f"
+         stroke-width="2"
+         stroke-dasharray="5,5"
+         stroke-linejoin="null"
+         stroke-linecap="round"
+         x1="128.666668"
+         y1="191.333333"
+         x2="128.666668"
+         y2="341.333333"
+         id="svg_35" />
+      <line
+         fill="none"
+         stroke="#7f7f7f"
+         stroke-width="2"
+         stroke-dasharray="5,5"
+         stroke-linejoin="null"
+         stroke-linecap="round"
+         x1="528.666668"
+         y1="191.333333"
+         x2="528.666668"
+         y2="341.333333"
+         id="svg_36" />
+    </g>
+  </g>
+  <g
+     inkscape:groupmode="layer"
+     id="layer1"
+     inkscape:label="Layer 1" />
+</svg>

images/hicks_law.svg

@@ -0,0 +1,36 @@
+<svg xmlns:xlink="http://www.w3.org/1999/xlink" width="18.644ex" height="2.843ex" style="vertical-align: -0.838ex;" viewBox="0 -863.1 8027.4 1223.9" role="img" focusable="false" xmlns="http://www.w3.org/2000/svg" aria-labelledby="MathJax-SVG-1-Title">
+<title id="MathJax-SVG-1-Title">{\displaystyle T=b\cdot \log _{2}(n+1)}</title>
+<rect style="fill:#ffffff" id="rect557" width="100%"  height="100%" x="0" y="-863.1" />
+<defs aria-hidden="true">
+<path stroke-width="1" id="E1-MJMATHI-54" d="M40 437Q21 437 21 445Q21 450 37 501T71 602L88 651Q93 669 101 677H569H659Q691 677 697 676T704 667Q704 661 687 553T668 444Q668 437 649 437Q640 437 637 437T631 442L629 445Q629 451 635 490T641 551Q641 586 628 604T573 629Q568 630 515 631Q469 631 457 630T439 622Q438 621 368 343T298 60Q298 48 386 46Q418 46 427 45T436 36Q436 31 433 22Q429 4 424 1L422 0Q419 0 415 0Q410 0 363 1T228 2Q99 2 64 0H49Q43 6 43 9T45 27Q49 40 55 46H83H94Q174 46 189 55Q190 56 191 56Q196 59 201 76T241 233Q258 301 269 344Q339 619 339 625Q339 630 310 630H279Q212 630 191 624Q146 614 121 583T67 467Q60 445 57 441T43 437H40Z"></path>
+<path stroke-width="1" id="E1-MJMAIN-3D" d="M56 347Q56 360 70 367H707Q722 359 722 347Q722 336 708 328L390 327H72Q56 332 56 347ZM56 153Q56 168 72 173H708Q722 163 722 153Q722 140 707 133H70Q56 140 56 153Z"></path>
+<path stroke-width="1" id="E1-MJMATHI-62" d="M73 647Q73 657 77 670T89 683Q90 683 161 688T234 694Q246 694 246 685T212 542Q204 508 195 472T180 418L176 399Q176 396 182 402Q231 442 283 442Q345 442 383 396T422 280Q422 169 343 79T173 -11Q123 -11 82 27T40 150V159Q40 180 48 217T97 414Q147 611 147 623T109 637Q104 637 101 637H96Q86 637 83 637T76 640T73 647ZM336 325V331Q336 405 275 405Q258 405 240 397T207 376T181 352T163 330L157 322L136 236Q114 150 114 114Q114 66 138 42Q154 26 178 26Q211 26 245 58Q270 81 285 114T318 219Q336 291 336 325Z"></path>
+<path stroke-width="1" id="E1-MJMAIN-22C5" d="M78 250Q78 274 95 292T138 310Q162 310 180 294T199 251Q199 226 182 208T139 190T96 207T78 250Z"></path>
+<path stroke-width="1" id="E1-MJMAIN-6C" d="M42 46H56Q95 46 103 60V68Q103 77 103 91T103 124T104 167T104 217T104 272T104 329Q104 366 104 407T104 482T104 542T103 586T103 603Q100 622 89 628T44 637H26V660Q26 683 28 683L38 684Q48 685 67 686T104 688Q121 689 141 690T171 693T182 694H185V379Q185 62 186 60Q190 52 198 49Q219 46 247 46H263V0H255L232 1Q209 2 183 2T145 3T107 3T57 1L34 0H26V46H42Z"></path>
+<path stroke-width="1" id="E1-MJMAIN-6F" d="M28 214Q28 309 93 378T250 448Q340 448 405 380T471 215Q471 120 407 55T250 -10Q153 -10 91 57T28 214ZM250 30Q372 30 372 193V225V250Q372 272 371 288T364 326T348 362T317 390T268 410Q263 411 252 411Q222 411 195 399Q152 377 139 338T126 246V226Q126 130 145 91Q177 30 250 30Z"></path>
+<path stroke-width="1" id="E1-MJMAIN-67" d="M329 409Q373 453 429 453Q459 453 472 434T485 396Q485 382 476 371T449 360Q416 360 412 390Q410 404 415 411Q415 412 416 414V415Q388 412 363 393Q355 388 355 386Q355 385 359 381T368 369T379 351T388 325T392 292Q392 230 343 187T222 143Q172 143 123 171Q112 153 112 133Q112 98 138 81Q147 75 155 75T227 73Q311 72 335 67Q396 58 431 26Q470 -13 470 -72Q470 -139 392 -175Q332 -206 250 -206Q167 -206 107 -175Q29 -140 29 -75Q29 -39 50 -15T92 18L103 24Q67 55 67 108Q67 155 96 193Q52 237 52 292Q52 355 102 398T223 442Q274 442 318 416L329 409ZM299 343Q294 371 273 387T221 404Q192 404 171 388T145 343Q142 326 142 292Q142 248 149 227T179 192Q196 182 222 182Q244 182 260 189T283 207T294 227T299 242Q302 258 302 292T299 343ZM403 -75Q403 -50 389 -34T348 -11T299 -2T245 0H218Q151 0 138 -6Q118 -15 107 -34T95 -74Q95 -84 101 -97T122 -127T170 -155T250 -167Q319 -167 361 -139T403 -75Z"></path>
+<path stroke-width="1" id="E1-MJMAIN-32" d="M109 429Q82 429 66 447T50 491Q50 562 103 614T235 666Q326 666 387 610T449 465Q449 422 429 383T381 315T301 241Q265 210 201 149L142 93L218 92Q375 92 385 97Q392 99 409 186V189H449V186Q448 183 436 95T421 3V0H50V19V31Q50 38 56 46T86 81Q115 113 136 137Q145 147 170 174T204 211T233 244T261 278T284 308T305 340T320 369T333 401T340 431T343 464Q343 527 309 573T212 619Q179 619 154 602T119 569T109 550Q109 549 114 549Q132 549 151 535T170 489Q170 464 154 447T109 429Z"></path>
+<path stroke-width="1" id="E1-MJMAIN-28" d="M94 250Q94 319 104 381T127 488T164 576T202 643T244 695T277 729T302 750H315H319Q333 750 333 741Q333 738 316 720T275 667T226 581T184 443T167 250T184 58T225 -81T274 -167T316 -220T333 -241Q333 -250 318 -250H315H302L274 -226Q180 -141 137 -14T94 250Z"></path>
+<path stroke-width="1" id="E1-MJMATHI-6E" d="M21 287Q22 293 24 303T36 341T56 388T89 425T135 442Q171 442 195 424T225 390T231 369Q231 367 232 367L243 378Q304 442 382 442Q436 442 469 415T503 336T465 179T427 52Q427 26 444 26Q450 26 453 27Q482 32 505 65T540 145Q542 153 560 153Q580 153 580 145Q580 144 576 130Q568 101 554 73T508 17T439 -10Q392 -10 371 17T350 73Q350 92 386 193T423 345Q423 404 379 404H374Q288 404 229 303L222 291L189 157Q156 26 151 16Q138 -11 108 -11Q95 -11 87 -5T76 7T74 17Q74 30 112 180T152 343Q153 348 153 366Q153 405 129 405Q91 405 66 305Q60 285 60 284Q58 278 41 278H27Q21 284 21 287Z"></path>
+<path stroke-width="1" id="E1-MJMAIN-2B" d="M56 237T56 250T70 270H369V420L370 570Q380 583 389 583Q402 583 409 568V270H707Q722 262 722 250T707 230H409V-68Q401 -82 391 -82H389H387Q375 -82 369 -68V230H70Q56 237 56 250Z"></path>
+<path stroke-width="1" id="E1-MJMAIN-31" d="M213 578L200 573Q186 568 160 563T102 556H83V602H102Q149 604 189 617T245 641T273 663Q275 666 285 666Q294 666 302 660V361L303 61Q310 54 315 52T339 48T401 46H427V0H416Q395 3 257 3Q121 3 100 0H88V46H114Q136 46 152 46T177 47T193 50T201 52T207 57T213 61V578Z"></path>
+<path stroke-width="1" id="E1-MJMAIN-29" d="M60 749L64 750Q69 750 74 750H86L114 726Q208 641 251 514T294 250Q294 182 284 119T261 12T224 -76T186 -143T145 -194T113 -227T90 -246Q87 -249 86 -250H74Q66 -250 63 -250T58 -247T55 -238Q56 -237 66 -225Q221 -64 221 250T66 725Q56 737 55 738Q55 746 60 749Z"></path>
+</defs>
+<g stroke="currentColor" fill="currentColor" stroke-width="0" transform="matrix(1 0 0 -1 0 0)" aria-hidden="true">
+ <use xlink:href="#E1-MJMATHI-54" x="0" y="0"></use>
+ <use xlink:href="#E1-MJMAIN-3D" x="982" y="0"></use>
+ <use xlink:href="#E1-MJMATHI-62" x="2038" y="0"></use>
+ <use xlink:href="#E1-MJMAIN-22C5" x="2690" y="0"></use>
+<g transform="translate(3191,0)">
+ <use xlink:href="#E1-MJMAIN-6C"></use>
+ <use xlink:href="#E1-MJMAIN-6F" x="278" y="0"></use>
+ <use xlink:href="#E1-MJMAIN-67" x="779" y="0"></use>
+ <use transform="scale(0.707)" xlink:href="#E1-MJMAIN-32" x="1809" y="-343"></use>
+</g>
+ <use xlink:href="#E1-MJMAIN-28" x="4924" y="0"></use>
+ <use xlink:href="#E1-MJMATHI-6E" x="5313" y="0"></use>
+ <use xlink:href="#E1-MJMAIN-2B" x="6136" y="0"></use>
+ <use xlink:href="#E1-MJMAIN-31" x="7137" y="0"></use>
+ <use xlink:href="#E1-MJMAIN-29" x="7637" y="0"></use>
+</g>
+</svg>

scripts/prepare-markdown-for-ebook.sh

@@ -0,0 +1,44 @@
+#!/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."

translations/es-ES.md

@@ -87,7 +87,7 @@ El diagrama de abajo muestra algunos ejemplos de mejoras potenciales en velocida
 
 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 paralelización es clave para mejorar 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).
+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:
 

translations/fr.md

@@ -0,0 +1,779 @@
+# 💻📖 hacker-laws
+
+Lois, théories, principes et modèles que les développeurs trouveront utiles.
+
+[Traductions](#translations): [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇩🇪](./translations/de.md) [🇫🇷](./translationis/fr.md) [🇬🇷](./translations/el.md) [🇮🇹](https://github.com/csparpa/hacker-laws-it) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](https://github.com/umutphp/hacker-laws-tr)
+
+Vous aimez ce projet ? N'hésitez pas à [me sponsoriser](https://github.com/sponsors/dwmkerr) ainsi que [les traducteurs](#traductions).
+
+---
+
+<!-- vim-markdown-toc GFM -->
+
+- [Introduction](#introduction)
+- [Lois](#lois)
+    - [Loi d'Amdahl](#loi-damdahl)
+    - [Théorie de la vitre brisée](#theorie-de-la-vitre-brisee)
+    - [Loi de Brooks](#loi-de-brooks)
+    - [Loi de Conway](#loi-de-conway)
+    - [Loi de Cunningham](#loi-de-cunningham)
+    - [Nombre de Dunbar](#nombre-de-dunbar)
+    - [Loi de Gall](#loi-de-gall)
+    - [Loi de Goodhart](#loi-de-goodhart)
+    - [Rasoir de Hanlon](#rasoir-de-hanlon)
+    - [Loi de Hofstadter](#loi-de-hofstadter)
+    - [Loi de Hutber](#loi-de-hutber)
+    - [Cycle du hype & Loi d'Amara](#cycle-de-hype--loi-damara)
+    - [Loi d'Hyrum (loi des interfaces implicites)](#loi-dhyrum)
+    - [Loi de Kernighan](#loi-de-kernighan)
+    - [Loi de Metcalfe](#loi-de-metcalfe)
+    - [Loi de Moore](#loi-de-moore)
+    - [Loi de Murphy / Loi de Sod](#loi-de-murphy--loi-de-sod)
+    - [Rasoir d'Occam](#rasoir-doccam)
+    - [Loi de Parkinson](#loi-de-parkinson)
+    - [Effet d'optimisation prématurée](#effet-doptimisation-prematuree)
+    - [Loi de Putt](#loi-de-putt)
+    - [Loi de Reed](#loi-de-reed)
+    - [Loi de la conservation de la complexité (Loi de Tesler)](#loi-de-tesler)
+    - [Loi des abstractions qui fuient](#loi-des-abstractions-qui-fuient)
+    - [Loi de futilité](#loi-de-futilite)
+    - [Philosophie d'Unix](#philosophie-dunix)
+    - [Modèle de Spotify](#modele-de-spotify)
+    - [Loi de Wadler](#loi-de-wadler)
+    - [Loi de Wheaton](#loi-de-wheaton)
+- [Principes](#principes)
+    - [Principe de Dilbert](#principe-de-dilbert)
+    - [Principe de Pareto (Regle des 80/20)](#principe-de-pareto-regle-des-8020)
+    - [Principe de Peter](#principe-de-peter)
+    - [Principe de robustesse (loi de Postel)](#principe-de-robustesse-loi-de-postel)
+    - [SOLID](#solid)
+    - [Principe de responsabilité unique](#principe-de-responsabilite-unique)
+    - [Principe ouvert/fermé](#principe-ouvertferme)
+    - [Principe de substitution de Liskov](#principe-de-substitution-de-liskov)
+    - [Principe de ségrégation des interfaces](#principe-de-segregation-des-interfaces)
+    - [Principe d'inversion des dépendances](#principe-dinversion-des-dependances)
+    - [Principe DRY](#principe-dry)
+    - [Principe KISS](#principe-kiss)
+    - [YAGNI](#yagni)
+    - [Illusions de l'informatique distribuée](#illusions-de-linformatique-distribuee)
+- [À lire](#a-lire)
+- [Traductions](#traductions)
+- [Projets liés](#projets-lies)
+- [Contribuer](#contribuer)
+- [TODO](#todo)
+
+<!-- vim-markdown-toc -->
+
+## Introduction
+
+Il y a beaucoup de "lois" dont les gens parlent quand on discute de développement. Ce repository offre une vue d'ensemble et une référence des plus communes. N'hésitez pas à partager et à proposer vos PRs !
+
+❗: Ce repo ne *préconise* aucune des lois, principes ou modèles qui y sont expliqués. Leur application devrait toujours être le sujet d'un débat, et dépend grandement de ce sur quoi vous travaillez.
+
+## Lois
+
+Nous y voila !
+
+### Loi d'Amdahl
+
+[Loi d'Amdahl sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_d%27Amdahl)
+
+> La loi d'Amdahl est une formule qui montre le *gain de vitesse potentiel* sur un calcul, obtenu en augmentant les ressources d'un système. Habituellement utilisé en calcul parallèle, elle peut prédire les bénéfices réels de l'accroissement du nombre de processeurs. Bénéfices qui sont limités par le potentiel du programme à être parallélisé.
+
+Prenons un exemple: si un programme est composé de 2 parties, la partie A devant être exécuté par un seul processeur et la partie B pouvant être parallélisée, alors on peut constater qu'ajouter plusieurs processeurs au système executant le programme ne peut avoir qu'un bénéfice limité. Cela peut potentiellement améliorer grandement la vitesse de la partie B, mais la vitesse de la partie A restera inchangée.
+
+Le diagramme ci-dessous montre quelques exemples de gain de vitesse potentiels :
+
+<img width="480px" alt="Diagram: Amdahl's Law" src="../images/amdahls_law.png">
+
+*(Reference: par Daniels220 sur English Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)*
+
+Comme il est visible, un programme qui est parallélisable à 50% ne bénéficiera que très peu au delà des 10 processeurs, tandis qu'un programme parallélisable à 95% peut encore gagner en vitesse avec plus d'un millier de processeurs.
+
+À mesure que la [loi de Moore](#loi-de-moore) ralenti et que l'accélération de la vitesse de calcul des processeurs diminue, la parallélisation est la clef de l'amélioration des performances. Prenons par exemple la programmation graphique avec les calculs de Shader: chaque pixel ou fragment peut être rendu en parallèle. Ce qui explique que les cartes graphiques récentes ont souvent plusieurs milliers de coeurs de calcul (GPUs ou Shader Units).
+
+Voir aussi:
+
+- [Loi de Brooks](#loi-de-brooks)
+- [Loi de Moore](#loi-de-moore)
+
+### Théorie de la vitre brisée
+
+[Théorie de la vitre brisée sur Wikipedia](https://fr.wikipedia.org/wiki/Hypoth%C3%A8se_de_la_vitre_bris%C3%A9e)
+
+La théorie de la vitre brisée suggère que des signes visibles de criminalité (ou de manque de soin d'un environnement) amène à des crimes plus nombreux et plus sérieux (ou une plus grande détérioration de l'environnement).
+
+Cette théorie est aussi appliqué au développement logiciel pour suggérer que du code de mauvaise qualité (ou de la [dette technique](#TODO)) peut amener à penser que les efforts fait pour améliorer le code ne sont pas valorisés, voir complètement ignorés. Menant ainsi à une plus grande détérioration de la qualité du code au fil du temps.
+
+Voir aussi:
+
+- [Dette technique](#TODO)
+
+Exemples:
+
+- [The Pragmatic Programming: Software Entropy](https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy)
+- [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/)
+
+### Loi de Brooks
+
+[Loi de Brooks sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_de_Brooks)
+
+> Ajouter des personnes à un projet en retard accroît son retard.
+
+Cette loi suggère que dans beaucoup de cas, tenter d'accélérer le bouclage d'un projet qui est en retard en ajoutant plus de personnes dessus rendra le projet encore plus en retard. Brooks est clair sur le fait qu'il s'agit d'une grande simplification, mais le raisonnement général est que la vitesse d'avancement du projet sur le court terme diminue à cause du temps nécessaire à l'intégration des nouveaux arrivants et du surplus de communication nécessaire. De plus, de nombreuses tâches peuvent ne pas être divisibles, comprendre réparties entre plusieurs personnes. Ce qui abaisse encore le potentiel d'augmentation de la vitesse d'avancement du projet.
+
+La phrase bien connue "Neuf femmes ne peuvent pas faire un bébé en un mois" illustre la loi de Brooks, en particulier le fait que certaines tâches ne sont pas divisibles ou parallélisables.
+
+C'est un thème central du livre '[The Mythical Man Month](#reading-list)'.
+
+Voir aussi:
+
+- [Death March](#todo)
+- [Reading List: The Mythical Man Month](#reading-list)
+
+### Loi de Conway
+
+[Loi de Conway sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_de_Conway)
+
+Cette loi suggère que les contours techniques d'un système reflètent la structure de l'organisation qui a produit le système. Cette loi est souvent évoquée quand on cherche à améliorer l'organisation en question. Si une organisation est structurée en plusieurs unités déconnectées, le logiciel qui est produit le sera aussi. Si une organisation est composée de silos verticaux orientés autour de fonctionnalités ou services, le logiciel le reflètera aussi.
+
+Voir aussi:
+
+- [Modèle de Spotify](#modele-de-spotify)
+
+### Loi de Cunningham
+
+[Loi de Cunningham sur Wikipedia](https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham's_Law)
+
+> Le meilleur moyen d'obtenir une bonne réponse sur Internet n'est pas de poser la question, mais de poster la mauvaise réponse.
+
+Selon Steven McGeady, Ward Cunningham lui aurait conseillé au début des années 1980: "le meilleur moyen d'obtenir une bonne réponse sur Internet n'est pas de poser la question, mais de poster la mauvaise réponse." McGeady baptisa cette phrase la loi de Cunningham, bien que Cunningham lui même en réfute la parenté. Faisant initialement référence aux interactions sur Usenet, cette loi a été utilisé pour décrire le fonctionnement d'autres communautés en ligne (Wikipedia, Reddit, Twitter, Facebook).
+
+Voir aussi:
+
+- [XKCD 386: "Duty Calls"](https://xkcd.com/386/)
+
+### Nombre de Dunbar
+
+[Nombre de Dunbar sur Wikipedia](https://fr.wikipedia.org/wiki/Nombre_de_Dunbar)
+
+"Le nombre de Dunbar est le nombre maximum d'individus avec lesquels une personne peut entretenir simultanément une relation humaine stable." À savoir une relation dans laquelle un individu sait qui est chaque personne et comment elle est liée aux autres personnes. Il n'y a pas de véritable consensus sur le nombre exact. "... [Dunbar] avance que les êtres humains peuvent maintenir confortablement seulement 150 relations stables". Il place le nombre dans un contexte social: "le nombre de personnes envers lesquelles vous ne vous sentiriez pas embarrassé de partager un verre si vous les croisiez par hasard dans un bar". Les estimations du nombre tombent généralement entre 100 et 250.
+
+De même que les relations stables entre individus, la relation entre un développeur et une codebase requiert des efforts pour être maintenu. Lorsque nous faisons face à de larges projets compliqués ou nombreux, nous pouvons nous aider de conventions, de procédures ou de modèles. Le nombre de Dunbar est important à garder à l'esprit non seulement lorsque la taille d'une entreprise augmente mais aussi lorsqu'on décide de la portée des efforts à réaliser pour une équipe. Pris dans un contexte d'ingénierie, il représente le nombre de projets sur lesquels on pourrait sereinement faire du support si on y était amené.
+
+Voir aussi :
+
+- [Loi de Conway](#loi-de-conway)
+
+### Loi de Gall
+
+[Loi de Gall sur Wikipedia](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law)
+
+> Un système complexe qui fonctionne est une évolution d'un système simple qui fonctionne. Un système complexe entièrement conçu depuis zero ne fonctionne jamais et ne peut pas être modifié pour le faire fonctionner. Il faut recommencer avec un système simple qui fonctionne.
+> ([John Gall](https://en.wikipedia.org/wiki/John_Gall_(author)))
+
+La loi de Gall implique que les tentatives de *concevoir* un système fortement complexe ont de grandes chances d'échouer. Les systèmes fortement complexes sont rarement construits d'un seul coup, mais évoluent plutôt depuis des systèmes plus simples.
+
+Un exemple classique est le world-wide-web. Dans son état actuel, il s'agit d'un système fortement complexe. Cependant, il était initialement définit comme un simple moyen d'échanger du contenu entre établissements universitaires. Ayant atteint cet objectif avec un grand succès, le système a évolué pour devenir de plus en plus complexe au fil du temps.
+
+Voir aussi :
+
+- [KISS (Keep It Simple, Stupid)](#principe-kiss)
+
+### Loi de Goodhart
+
+[Loi de Goodhart sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_de_Goodhart)
+
+> Toute régularité statistique observée a tendance à perdre de sa fiabilité lorsque on tente de la contrôler.
+> *Charles Goodhart*
+
+Souvent aussi énoncée de cette manière :
+
+> Lorsqu'une mesure devient un objectif, elle cesse d'être une bonne mesure.
+> *Marilyn Strathern*
+
+Cette loi indique que les optimisations basées sur une mesure peuvent amener à une perte de valeur de la mesure elle même. Un ensemble de mesures ([KPIs](https://en.wikipedia.org/wiki/Performance_indicator)) trop restraint appliqué aveuglément à un process déforme le résultat. Les gens tendent à "tricher" localement pour satisfaire une mesure en particulier sans faire attention aux effets globaux de leurs actions sur le système.
+
+Exemples concrets :
+
+- Il est possible d'atteindre un taux de couverture du code arbitraire en rédigeant des tests qui ne vérifient rien. Alors que le but initial de la mesure était d'avoir du code correctement testé.
+- Mesurer les performances des développeurs avec le nombre de lignes de code rédigées amène à des codebases inutilement grosses.
+
+Voir aussi :
+
+- [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)
+
+### Rasoir de Hanlon
+
+[Rasoir de Hanlon sur Wikipedia](https://fr.wikipedia.org/wiki/Rasoir_de_Hanlon)
+
+> Ne jamais attribuer à la malveillance ce que la bêtise suffit à expliquer.
+> Robert J. Hanlon
+
+Ce principe suggère que des actions produisant un mauvais résultat ne sont pas toujours motivées par de mauvaises intentions. Il est au contraire plus probable que le problème se situe dans la compréhension de ces actions et de leurs impacts.
+
+### Loi de Hofstadter
+
+[Loi de Hofstadter sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_de_Hofstadter)
+
+> Il faut toujours plus de temps que prévu, même en tenant compte de la loi de Hofstadter.
+> (Douglas Hofstadter)
+
+Vous pourrez entendre parler de cette loi lorsqu'on cherche à estimer le temps nécessaire pour faire quelque chose. C'est un lieu commun de dire que nous ne sommes pas très bon pour estimer le temps nécessaire à boucler un projet en développement logiciel.
+
+c'est un extrait du livre '[Gödel, Escher, Bach: An Eternal Golden Braid](#a-lire)'.
+
+Voir aussi :
+
+- [À lire: Gödel, Escher, Bach: An Eternal Golden Braid](#a-lire)
+
+### Loi de Hutber
+
+[Loi de Hutber sur Wikipedia](https://en.wikipedia.org/wiki/Hutber%27s_law)
+
+> Amélioration veut dire détérioration.
+> ([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber))
+
+Cette loi suggère que les améliorations apportées à un système vont mener à la détérioration d'autres choses. Ou qu'elles vont cacher d'autres détériorations, amenant globalement à une dégradation de l'état du système.
+
+Par exemple, un abaissement de la latence de réponse sur une route (end-point) peut causer des problèmes de débit et de capacité plus loin, affectant un sous-système entièrement différent.
+
+### Cycle du hype & Loi d'Amara
+
+[Cycle du hype sur Wikipedia](https://fr.wikipedia.org/wiki/Cycle_du_hype)
+
+> On a tendance à surestimer l'effet d'une technologie sur le court terme et à le sous-estimer sur le long terme.
+> (Roy Amara)
+
+Le cycle du hype est une représentation visuelle de l'attrait et du développement d'une technologie au fil du temps. Initialement réalisé par Gartner, le concept est plus clair avec un diagramme :
+
+![The Hype Cycle](../images/gartner_hype_cycle.png)
+
+*(Reference: par Jeremykemp sur English Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)*
+
+En clair, ce cycle montre qu'il y a généralement un pic d'excitation concernant les nouvelles technologies et leur potentiel impact. Les équipes adoptent ces technologies rapidement et se retrouvent parfois déçues des résultats. Cela peut être à cause d'un manque de maturité de la technologie, ou parce que les applications concrètes de cette technologie ne sont pas encore totalement maitrisées. Après un certain temps, les opportunités d'utiliser cette technologie ainsi que ses capacités augmentent suffisamment pour que les équipes deviennent vraiment productives. La citation de Roy Amara le résume de manière plus succincte: "On a tendance à surestimer l'effet d'une technologie sur le court terme et à le surestimer sur le long terme".
+
+### Loi d'Hyrum (loi des interfaces implicites)
+
+[Loi d'Hyrum en ligne](http://www.hyrumslaw.com/)
+
+> Passé un certain nombre d'utilisateur d'une API, peu importe ce qui est promis par l'interface, tous les comportements possibles du système seront utilisés.
+> (Hyrum Wright)
+
+La loi d'Hyrum décris le fait que lorsqu'une API a un *nombre suffisamment élevé d'utilisateurs*, tous les comportements de l'API (y compris ceux qui ne sont pas définis publiquement) seront utilisés par quelqu'un. Un exemple trivial peut concerner les éléments non fonctionnels de l'API comme le temps de réponse. Un exemple plus subtil peut être l'utilisation d'une regex sur les messages d'erreurs pour en déterminer le *type*. Même si la spécification de l'API ne mentionne rien quant au contenu des messages, *certains* utilisateurs peuvent utiliser ces messages. Un changement au niveau de ces messages reviendrait à casser l'API pour ces utilisateurs.
+
+Voir aussi :
+
+- [Loi des abstractions qui fuient](#loi-des-abstractions-qui-fuient)
+- [XKCD 1172](https://xkcd.com/1172/)
+
+### Loi de Kernighan
+
+> Debugger est deux fois plus difficile que de rédiger le code initial. Par conséquent si vous rédiger le code de manière aussi maligne que possible, vous n'êtes, par définition, pas assez intelligent pour le debugger.
+> (Brian Kernighan)
+
+La loi de Kernighan est nommée d'après [Brian Kernighan](https://en.wikipedia.org/wiki/Brian_Kernighan) et est basée d'une citation du livre de Kernighan et Plauger: [The Elements of Programming Style](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style).
+
+> Tout le monde sait que debugger est 2 fois plus difficile que de rédiger le programme en premier lieu. Donc si vous êtes aussi malin que possible en le rédigeant, comment pourrez vous le debugger ?
+
+Bien qu'étant hyperbolique, la loi de Kernighan présente l'argument que du code simple est préférable à du code complexe, car tout problème qui pourrait apparaitre dans du code complexe sera couteux voir impossible à debugger.
+
+Voir aussi :
+
+- [Principe KISS](#principe-kiss)
+- [Philosophie d'Unix](#philosophie-dunix)
+- [Rasoir d'Occam](#rasoir-doccam)
+
+### Loi de Metcalfe
+
+[Loi de Metcalfe sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_de_Metcalfe)
+
+> L’utilité d’un réseau est proportionnelle au carré du nombre de ses utilisateurs.
+
+Cette loi est basée sur le nombre de connexions par pair à l'intérieur d'un système et est fortement liée à la [Loi de Reed](#loi-de-reed). Odlyzko et d'autres ont soutenus l'argument que la loi de Reed et la loi de Metcalfe surestiment la valeur du système en ne tenant pas compte des limites de l'intellect humain. Voir le [Nombre de Dunbar](#nombre-de-dunbar).
+
+Voir aussi :
+
+- [Loi de Reed](#loi-de-reed)
+- [Nombre de Dunbar](#nombre-de-dunbar)
+
+### Loi de Moore
+
+[Loi de Moore sur Wikipedia](https://en.wikipedia.org/wiki/Moore%27s_law)
+
+> Le nombre de transistors dans un circuit intégré double approximativement tous les 2 ans.
+
+Souvent utilisée pour illustrer la grande vitesse à laquelle les semi-conducteurs et les technologies de puces informatiques ont évoluées. Cette prédiction de Moore s'est révélée être très précise des années 70 aux années 2000. Plus récemment ceci dit, la tendance a ralentie, en partie du [aux limites physiques de la miniaturisation des composants](https://en.wikipedia.org/wiki/Quantum_tunnelling). Cependant, les avancées dans la parallélisation et les changements potentiellement révolutionnaires dans les technologies des semi-conducteurs et du calcul quantique continueront peut être de faire respecter la loi de Moore pour les décennies à venir.
+
+### Loi de Murphy / Loi de Sod
+
+[Loi de Murphy sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_de_Murphy)
+
+> Tout ce qui est susceptible d'aller mal, ira mal.
+
+Énoncée par [Edward A. Murphy, Jr](https://en.wikipedia.org/wiki/Edward_A._Murphy_Jr.), la *loi de Murphy* déclare que si quelque chose peut mal tourner, cela tournera mal.
+
+C'est une formule bien connue des développeurs. Parfois l'inattendu surviens lors du développement, des tests, ou même en production. Cette loi peut aussi être liée à la *loi de Sod* (plus courante en Anglais d'Angleterre) :
+
+> Si quelque chose peut mal tourner, cela tournera mal. Au pire moment possible.
+
+Ces 'lois' sont souvent utilisées dans un sens humoristique. Cependant, des biais cognitifs tels que le [*biais de confirmation*](#TODO) et le [*biais de sélection*](#TODO) peuvent amener des gens à porter trop d'importance à ces lois. (On ne porte pas attention aux choses quand elles fonctionnent, la plupart du temps. Quand il y a un problème en revanche, c'est plus remarqué et peut entrainer des discussions)
+
+Voir aussi :
+
+- [Biais de confirmation](#TODO)
+- [Biais de sélection](#TODO)
+
+### Rasoir d'Occam
+
+[Rasoir d'Occam sur Wikipedia](https://fr.wikipedia.org/wiki/Rasoir_d%27Ockham)
+
+> Les multiples ne doivent pas être utilisés sans nécessité.
+> William of Ockham
+
+Le rasoir d'Occam nous indique que parmi plusieurs solutions possibles, la plus probable est celle à laquelle est attachée le moins de concepts et d'à priori. Cette solution est la plus simple et résout le problème donné sans ajouter accidentellement de la complexité et de potentielles conséquences négatives.
+
+Voir aussi :
+
+- [YAGNI](#yagni)
+- [No Silver Bullet: Accidental Complexity and Essential Complexity](https://en.wikipedia.org/wiki/No_Silver_Bullet)
+
+Exemple :
+
+- [Lean Software Development: Eliminate Waste](https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste)
+
+### Loi de Parkinson
+
+[Loi de Parkinson sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_de_Parkinson)
+
+> Le travail s’étale de façon à occuper le temps disponible pour son achèvement.
+
+Dans son contexte original, cette loi était basée sur l'étude des administrations. Elle peut être appliquée aux projets de développement logiciel, la théorie étant que les équipes seront inefficaces jusqu'à l'approche des deadlines puis se dépêcheront de finir le travail pour tenir les délais. Rendant la deadline plus ou moins arbitraire.
+
+Si cette loi est combinée avec la [loi de Hofstadter](#loi-de-hofstadter), on arrive à une perspective encore plus pessimiste: le travail s'étale pour occuper tout le temps disponible et au final prendra *encore plus de temps que prévu*.
+
+Voir aussi :
+
+- [Loi de Hofstadter](#loi-de-hofstadter)
+
+### Effet d'optimisation prématurée
+
+[Optimisation prématurée sur WikiWikiWeb](http://wiki.c2.com/?PrematureOptimization)
+
+> L'optimisation prématurée est la source de tous les maux.
+> [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en)
+
+Dans l'article [Structured Programming With Go To Statements](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements) rédigé par Donald Knuth, celui-ci écrit : "Les programmeurs perdent un temps énorme à réfléchir ou à se soucier de la vitesse de certaines parties non-critiques de leurs programmes. Et ces tentatives d'être performant ont en vérité un impact fortement négatif quand on prend en compte le debugging et la maintenance. Nous devrions oublier les petits rendements. Disons que 97% du temps: **l'optimisation prématurée est la source de tous les maux**. Ceci dit, nous ne devrions pas louper les opportunités disponibles dans ces 3% cruciaux."
+
+*L'optimisation prématurée* peut aussi être définie plus simplement comme: optimiser avant qu'on soit sûr qu'il faille le faire.
+
+### Loi de Putt
+
+[Loi de Putt sur Wikipedia](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat)
+
+> La technologie est dominée par deux types de personnes: celles qui comprennent ce qu'elles ne managent pas et celles qui managent ce qu'elles ne comprennent pas.
+
+La loi de Putt est souvent suivie par sa corollaire :
+
+> Toute hiérarchie technique développe tôt ou tard une inversion de compétence.
+
+Ces déclarations suggèrent que étant donné les divers critères de sélection et tendances dans la manière dont les groupes s'organisent, on trouvera au sein d'une entreprise technique deux types d'employés: des employés compétents techniquement non cadres et des employés à des postes de gestion qui ne comprennent pas aussi bien la complexité et les difficultés techniques. Cela peut être attribué à des phénomènes comme le [principe de Peter](#principe-de-peter) or le [principe de Dilbert](#principe-de-dilbert).
+
+Ceci dit, il est important de préciser que ce genre de lois sont des généralisations et s'appliquent à *certains* types d'organisation, sans s'appliquer à d'autres.
+
+Voir aussi :
+
+- [Principe de Peter](#principe-de-peter)
+- [Principe de Dilbert](#principe-de-dilbert)
+
+### Loi de Reed
+
+[Loi de Reed sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_de_Reed)
+
+> L'utilité des grands réseaux, particulièrement des réseaux sociaux, s'accroit exponentiellement avec la taille du réseau.
+
+Cette loi est basée sur la théorie des graphs, où l'utilité s'accroit avec le nombre de sous-groupes possibles. Odlyzko et d'autres ont avancé l'argument que la loi de Reed surestime l'utilité du réseau en ne prenant pas en compte les limites du cerveau humain; voir le [nombre de Dunbar](#nombre-de-dunbar).
+
+Voir aussi :
+
+- [Loi de Metcalfe](#loi-de-metcalfe)
+- [Nombre de Dunbar](#nombre-de-dunbar)
+
+### Loi de la conservation de la complexité (Loi de Tesler)
+
+[Loi de la conservation de la complexité sur Wikipedia](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity)
+
+Cette loi énonce qu'il y a une certaine quantité de complexité dans un système qui ne peut pas être réduite.
+
+Une partie de la complexité d'un système est du à de la négligence. Conséquence d'une mauvaise structure, d'erreurs ou d'une mauvaise modélisation du problème à résoudre. Ce type de complexité peut être réduit, voir éliminé. Cependant, il y a une autre partie de la complexité qui est intrinsèque, du au problème qu'on cherche à résoudre. Ce type de complexité peut être déplacé mais pas éliminé.
+
+Un élément interessant soulevé par cette loi est la suggestion que même en simplifiant le système en entier, la complexité intrinsèque n'est pas réduite, elle est *déportée sur l'utilisateur*, qui doit alors compenser.
+
+### Loi des abstractions qui fuient
+
+[Loi des abstractions qui fuient sur Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/)
+
+> Toutes les abstractions non-triviales fuient plus ou moins.
+> ([Joel Spolsky](https://twitter.com/spolsky))
+
+Cette loi énonce que les abstractions, qui sont généralement utilisé en informatique pour simplifier l'utilisation de systèmes complexes, vont "fuirent" une partie du système sous-jacent dans certaines situations.
+
+Si on prends l'exemple de la lecture d'un fichier. Les APIs pour les systèmes de fichier sont une *abstraction* des systèmes plus bas niveau du kernel, qui sont eux même une abstraction du processus physique de changement de données sur le disque (ou la mémoire flash pour un SSD). Dans la plupart des cas, l'abstraction consistant à traiter un fichier comme un flux de données binaire fonctionnera comme prévu. Cependant, avec un disque magnétique la lecture de données séquentielle sera *significativement* plus rapide que la lecture de données aléatoire (due aux couts plus élevés d'erreurs de page). Mais pour un disque SSD, ces couts supplémentaires n'existent pas. On peut donc voir que les détails sous-jacents doivent être compris pour gérer cet exemple efficacement (par exemple les fichiers d'index de base de données sont structurés de manière à limiter le surcout des accès aléatoires). L'abstraction "fuit" certains détails d'implémentation que le développeur peut donc avoir besoin de connaitre.
+
+L'exemple ci-dessus peut devenir plus complexe quand des abstractions *supplémentaires* sont présentes. Par exemple, le système d'exploitation Linux permet aux fichiers d'accéder à des fichiers via un réseau, mais les présente sur la machine comme étant "normaux". Cette abstraction va fuir s'il y a des problèmes de réseau. Si un développeur traite ces fichiers comme étant "normaux" sans considérer le fait qu'ils peuvent être sujets à de la latence ou des échecs réseaux, le logiciel fonctionnera mal.
+
+L'article décrivant cette loi suggère qu'une dépendance trop forte aux abstractions combinée à une faible compréhension des processus sous-jacent rend le problème *plus* complexe à gérer dans certains cas.
+
+Voir aussi :
+
+- [Loi d'Hyrum](#loi-dhyrum)
+
+Exemples concrets :
+
+- - [Démarrage lent de Photoshop](https://forums.adobe.com/thread/376152) - un problème que j'ai eut par le passé. Photoshop était lent au démarrage, prenant parfois plusieurs minutes. Le problème venait du fait que le logiciel récupérait des informations sur l'imprimante par défaut au démarrage. Hors, si cette imprimante était reliée par réseau, cela prenait extrêmement longtemps. *L'abstraction* de l'imprimante réseau présentée comme étant similaire à une imprimante locale causait ce problème pour les utilisateurs avec une mauvaise connexion.
+
+### Loi de futilité
+
+[Loi de futilité sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_de_futilit%C3%A9_de_Parkinson)
+
+Cette loi suggère que les organisations donnent largement plus de temps et d'attention à des détails triviaux ou cosmétiques qu'aux problèmes fondamentaux et difficiles.
+
+L'exemple fictif couramment utilisé est celui d'un comité approuvant les plans d'une centrale nucléaire et qui passe la majorité de son temps à parler du local à vélo plutôt que de la conception de la centrale en elle même. Il peut être difficile de participer de manière utile à des discussions concernant des sujets vastes et complexes sans une grande expertise ou préparation. Cependant les gens veulent être vu comme participant de manière utile. D'où une tendance à trop se focaliser sur des détails qui peuvent être abordés simplement mais qui n'ont pas particulièrement d'importance.
+
+L'exemple ci-dessus à conduit à l'utilisation du terme 'Bike Shedding' (en rapport à l'abri à vélo) comme expression désignant une perte de temps sur des détails triviaux. Un autre terme apparenté est '[Yak Shaving](https://en.wiktionary.org/wiki/yak_shaving)', qui désigne une activité apparemment inutile qui fait partie d'une longe chaine de pré-requis à la tâche principale.
+
+### Philosophie d'Unix
+
+[The Unix Philosophie d'Unix sur Wikipedia](https://fr.wikipedia.org/wiki/Philosophie_d%27Unix)
+
+La philosophie d'Unix consiste à dire que les programmes informatiques doivent être petits, ne faire qu'une seule chose et la faire bien. Cela peut rendre plus simple la construction de systèmes en combinant des unités simples petites et bien définies plutôt que des programmes larges, complexes et servant à plusieurs choses.
+
+Certaines pratiques récentes comme l'architecture en microservices peut être vue comme une application de cette loi, où les services sont petits et ne font qu'une seule chose, permettant la création de comportements complexes à partir de briques qui sont simples.
+
+### Modèle de Spotify
+
+[Modèle de Spotify sur Spotify Labs](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/)
+
+Le modèle de Spotify est une approche à la structure d'entreprise et des équipes qui a été popularisée par Spotify. Dans ce modèle, les équipes sont organisées autour des fonctionnalités plutôt que des technologies.
+
+Le modèle de Spotify a également popularisé les concepts de Tribus, Guildes, et Chapitres qui sont d'autres éléments de leur structure.
+
+### Loi de Wadler
+
+[Loi de Wadler sur wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law)
+
+> Dans toute conception de langage, le temps total passé à discuter un aspect de cette liste est proportionnel à deux élevé à la puissance de la position correspondante.
+> 1. Sémantique
+> 2. Syntaxe
+> 3. Syntaxe lexicale
+> 4. Syntaxe lexicale des commentaires
+> (en clair, pour chaque heure passée sur la sémantique, 8 heures seront passées sur la syntaxe des commentaires)
+
+Similaire à la [loi de trivialité](#loi-de-futilite), la loi de Wadler énonce que lors de la conception d'un langage, le temps passé à discuter des différents aspects est inversement proportionnel à l'importance de ces aspects.
+
+Voir aussi :
+
+- [Loi de futilité](#loi-de-futilite)
+
+### Loi de Wheaton
+
+[Le lien](http://www.wheatonslaw.com/)
+
+[Le jour officiel](https://dontbeadickday.com/)
+
+> Ne soyez pas un connard.
+> *Wil Wheaton*
+
+Inventée par Will Wheaton (Star Trek: The Next Generation, The Big Bang Theory), cette loi simple, concise et puissante vise à augmenter l'harmonie et le respect au sein d'un environnement professionnel. Elle peut être appliquée lorsqu'on parle à ses collègues, effectue une revue de code (*code review*), argumente contre un autre point de vue, critique et de manière générale, lors de la plupart des interactions entre humains.
+
+## Principes
+
+Les principes sont généralement des lignes directrices liés à la conception.
+
+### Principe de Dilbert
+
+[Principe de Dilbert sur Wikipedia](https://fr.wikipedia.org/wiki/Principe_de_Dilbert)
+
+> Les entreprises tendent à promouvoir systématiquement les employés incompétents afin de les sortir du workflow.
+> *Scott Adams*
+
+Un concept de gestion inventé par Scott Adams (créateur du comic strip Dilbert) inspiré par le [principe de Peter](#principe-de-peter). Suivant le principe de Dilbert, les employés qui n'ont jamais montré de compétence dans leur travail sont promus à des postes de management afin de limiter les dommages qu'ils peuvent causer. Adams expliqua initialement le principe dans un article du Wall Street Journal datant de 1995, et élabora le concept dans son livre de 1996: [The Dilbert Principle](#a-lire).
+
+Voir aussi :
+
+- [Principe de Peter](#principe-de-peter)
+- [Loi de Putt](#loi-de-putt)
+
+### Principe de Pareto (règle des 80/20)
+
+[Principe de Pareto sur Wikipedia](https://fr.wikipedia.org/wiki/Principe_de_Pareto)
+
+> La plupart des choses dans la vie ne sont pas réparties également.
+
+Le principe de Pareto suggère que dans certains cas, la majorité des résultats provient d'une minorité des actions :
+
+- 80% d'un certain logiciel peut être écrit en 20% du temps de développement alloué (inversement, les 20% les plus difficiles prennent 80% du temps)
+- 20% de l'effort fourni produit 80% du résultat
+- 20% du travail amène 80% des revenus
+- 20% des bugs causent 80% des crashs
+- 20% des fonctionnalités entrainent 80% de l'utilisation
+
+Dans les années 1940, l'ingénieur Américano-Roumain Dr. Joseph Juran, qui est largement crédité comme étant le père du contrôle qualité, [commença à appliquer le principe de Pareto pour résoudre des problèmes de qualité](https://en.wikipedia.org/wiki/Joseph_M._Juran).
+
+Ce principe est aussi connu comme la règle des 80/20, 'The Law of the Vital Few' et 'The Principle of Factor Sparsity'.
+
+Exemples concrets :
+
+- - En 2002, Microsoft reporta qu'en réglant les 20% des bugs les plus reportés, 80% des erreurs et des crashs liés dans Windows et Office ont été éliminés ([Reference](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)).
+
+### Principe de Peter
+
+[Principe de Peter sur Wikipedia](https://en.wikipedia.org/wiki/Peter_principle)
+
+> Les gens faisant partie d'une hiérarchie tendent à s'élever à leur "niveau d'incompétence"
+> *Laurence J. Peter*
+
+Le principe de Peter est un concept de management inventé par Laurence J. Peter qui observe que les gens qui sont bons dans leur travail sont promus jusqu'à ce qu'ils atteignent un niveau où ils ne réussissent plus (leur "niveau d'incompétence"). À ce point, étant donné leur expérience ils sont moins susceptibles de se faire renvoyer (à part s'ils obtiennent des résultats particulièrement mauvais) et vont demeurer dans un poste pour lequel ils ont potentiellement peu de compétences.
+
+Ce principe est particulièrement intéressant pour les ingénieurs qui démarrent leur carrière dans des postes profondément techniques mais évoluent souvent vers des postes de *managers*, qui requiert des compétences fondamentalement différentes.
+
+Voir aussi :
+
+- [Principe de Dilbert](#principe-de-dilbert)
+- [Loi de Putt](#loi-de-putt)
+
+### Principe de robustesse (loi de Postel)
+
+[Principe de robustesse sur Wikipedia](https://fr.wikipedia.org/wiki/Jon_Postel#Principe_de_robustesse)
+
+> Soyez tolérant dans ce que vous acceptez, et pointilleux dans ce que vous envoyez
+
+Souvent appliqué dans le développement d'application serveur, ce principe énonce que ce que vous envoyez aux autres devrait être aussi minimal et conforme que possible. Mais que vous devriez accepter des données en entrée non-conforme si elles peuvent être traités.
+
+Le but de ce principe est de construire des systèmes qui sont robustes dans le sens où ils peuvent gérer des entrées mal formées du moment qu'elles restent compréhensibles. Cependant, il y a de potentielles implications de sécurité à accepter des entrés mal formées. Particulièrement si le traitement de ces entrées n'est pas correctement testé.
+
+À terme, autoriser des entrées non-conforme peut amoindrir la capacité d'évolution des protocoles étant donné que les utilisateurs vont tôt ou tard compter sur cette tolérance lors de leur utilisation.
+
+Voir aussi :
+
+- [Loi d'Hyrum](#loi-dhyrum)
+
+### SOLID
+
+Il s'agit d'un acronyme qui signifie :
+
+- S: [Single responsibility principle](#principe-de-responsabilite-unique) (principe de responsabilité unique)
+- O: [The Open/Closed Principle](#principe-ouvertferme) (principe ouvert/fermé)
+- L: [The Liskov Substitution Principle](#principe-de-substitution-de-liskov) (Principe de substitution de Liskov)
+- I: [The Interface Segregation Principle](#principe-de-segregation-des-interfaces) (principe de ségrégation des interfaces)
+- D: [Principe d'inversion des dépendances](#principe-dinversion-des-dependances)
+
+Ces principes sont fondamentaux dans la [programmation orientée objet](#TODO). Ces principes de conception devraient pouvoir aider les développeurs à construire des systèmes plus facilement maintenable.
+
+### Principe de responsabilité unique
+
+[Principe de responsabilité unique sur Wikipedia](https://en.wikipedia.org/wiki/Single_responsibility_principle)
+
+> Chaque module ou classe ne doit avoir qu'une seule responsabilité.
+
+Le premier des principes '[SOLID](#solid)'. Il suggère que les modules ou classes ne devraient faire qu'une chose unique. Autrement dit, un seul petit changement sur une fonctionnalité d'un programme ne devrait nécessiter de changer qu'un seul composant. Par exemple, changer la manière de valider un mot de passe ne devrait nécessiter un changement qu'à un endroit du programme.
+
+Théoriquement, cela devrait rendre le code plus robuste et plus simple à modifier. Savoir qu'un composant en train d'être modifié possède une seule responsabilité veut aussi dire que *tester* cette modification devrait être plus simple. Pour reprendre l'exemple precedent, changer le composant concernant la validation d'un mot de passe ne devrait affecter que cette fonctionnalité. Il est souvent beaucoup plus difficile de réfléchir aux impacts d'un changement sur un composant qui est responsable de plusieurs choses.
+
+Voir aussi :
+
+- [Programmation orientée objet](#todo)
+- [SOLID](#solid)
+
+### Principe ouvert/fermé
+
+[Principe ouvert/fermé sur Wikipedia](https://fr.wikipedia.org/wiki/Principe_ouvert/ferm%C3%A9)
+
+> Les entités devraient être ouvertes à l'extension et fermées à la modification.
+
+Le deuxième des principes '[SOLID](#solid)'. Il énonce que le comportement des entités (classes, modules, fonctions, etc.) devrait être *étendu*, mais que le comportement *existant* ne devrait pas être modifié.
+
+Imaginons par exemple un module capable de changer un document rédigé en Markdown en HTML. Ce module peut être étendu en y ajoutant le support pour une nouvelle fonctionnalité Markdown sans modifier son fonctionnement interne. Le module est en revanche *fermé* à la modification dans le sens où un utilisateur *ne peut pas* changer la manière dont le code existant est rédigé.
+
+Ce principe est particulièrement pertinent pour la programmation orientée objet, où on cherche la plupart du temps à concevoir des objets qu'on puisse facilement étendre mais dont le comportement existant ne puisse pas être modifié de manière imprévue.
+
+Voir aussi :
+
+- [Programmation orientée objet](#todo)
+- [SOLID](#solid)
+
+### Principe de substitution de Liskov
+
+[Principe de substitution de Liskov sur Wikipedia](https://fr.wikipedia.org/wiki/Principe_de_substitution_de_Liskov)
+
+> Il devrait être possible de remplacer un type avec un sous-type sans casser le système.
+
+Le troisième des principes '[SOLID](#solid)'. Il énonce que si un composant repose sur un type, alors il devrait être capable d'utiliser un sous-type de ce type sans que le système ne plante ou qu'il y ai besoin de connaitre les détails de ce sous-type.
+
+Imaginons par exemple que nous ayons une méthode qui lit un document XML depuis une structure représentant un fichier. Si cette méthode utilise un type 'fichier' de base, alors tous les types dérivant de 'fichier' devraient pouvoir être utilisé avec cette fonction. Si 'fichier' supporte une recherche partant de la fin et que le parser XML utilise cette fonction, mais que le type dérivé 'fichier réseau' ne permet pas de recherche en partant de la fin, alors 'fichier réseau' viole le principe.
+
+Ce principe est particulièrement pertinent pour la programmation orientée objet, où les hierarchies de types doivent être conçues soigneusement pour éviter de brouiller les utilisateurs d'un système.
+
+Voir aussi :
+
+- [Programmation orientée objet](#todo)
+- [SOLID](#solid)
+
+### Principe de ségrégation des interfaces
+
+[Principe de ségrégation des interfaces sur Wikipedia](https://fr.wikipedia.org/wiki/Principe_de_s%C3%A9gr%C3%A9gation_des_interfaces)
+
+> Aucun client de devrait dépendre de méthodes qu'il n'utilise pas.
+
+Le quatrième des principes '[SOLID](#solid)'. Celui-ci énonce que les utilisateurs d'un composant ne devraient pas dépendre des fonctions de ce composant qu'il n'utilise pas.
+
+Par exemple, imaginons que nous ayons une méthode qui lit un document XML depuis une structure représentant un fichier. Elle nécéssite seulement de pouvoir lire des octets, avancer ou reculer dans le fichier. Le principe sera invalidé si cette méthode a besoin d'être mise à jour lorsqu'une fonctionnalité sans rapport du fichier change (ex. une mise à jour de modèle de permissions pour l'accès au fichier). Il serait préférable pour le fichier d'implémenter une interface 'seekable-stream', et pour le lecteur XML de l'utiliser.
+
+Ce principe est particulièrement pertinent pour la programmation orientée objet, où les interfaces, hierarchies et type abstraits sont utilisés pour [minimiser le couplage](#todo) entre les différents composants. Le [duck typing](#todo) est une méthode qui applique ce principe en éliminant les interfaces explicites.
+
+Voir aussi :
+
+- [Programmation orientée objet](#todo)
+- [SOLID](#solid)
+- [Duck Typing](#todo)
+- [Decouplage](#todo)
+
+### Principe d'inversion des dépendances
+
+[Principe d'inversion des dépendances sur Wikipedia](https://fr.wikipedia.org/wiki/Inversion_des_d%C3%A9pendances)
+
+> Les modules de haut niveau ne devraient pas dépendre des implémentations de bas niveau.
+
+Le cinquième des principes '[SOLID](#solid)'. Il énonce que les composants de hauts niveau ne devraient pas avoir à connaitre les détails de leurs dependences.
+
+Prenons par exemple un programme qui lit des méta-donnés depuis un site web. Ce programme possède un composant principal qui connait un autre composant chargé de télécharger le contenu de la page, ainsi qu'un autre composant capable de lire les méta-donnés. En prenant en compte le principe d'inversion des dépendances, le composant principal ne devrait dépendre que de: un composant abstrait capable de télécharger des données binaires, ainsi que d'un composant abstrait capable de lire des méta-donnés depuis un flux binaire. Le composant principal ne devrais pas à connaitre les concepts de TCP/IP, HTTP, HTML, etc.
+
+Ce principe est complexe étant donné qu'il semble 'inverser' les dépendances attendues dans un système (d'où le nom). En pratique cela veut aussi dire qu'un composant 'orchestrateur' doit s'assurer que les types abstraits soient correctement implémentés. (Pour reprendre l'exemple précédent, *quelque chose* doit fournir un downloader de fichier HTTP et un liseur de meta tag HTML au composant lisant les méta-donnés.) On touche alors à des patterns tels que l'[inversion de contrôle](#todo) et l'[injection de dépendances](#todo).
+
+Voir aussi :
+
+- [Programmation orientée objet](#todo)
+- [SOLID](#solid)
+- [Inversion de contrôle](#todo)
+- [Injection de dépendances](#todo)
+
+### Principe DRY
+
+[Principe DRY sur Wikipedia](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)
+
+> Dans un système, toute connaissance doit avoir une représentation unique, non-ambiguë, faisant autorité.
+
+DRY est un acronyme pour *Don't Repeat Yourself* (ne vous répétez pas). Ce principe vise à aider les développeurs à réduire les répétitions de code et à garder l'information à un seul endroit. Il a été formulé en 1999 par Andrew Hunt et Dave Thomas dans le livre [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer).
+
+> L'opposé de DRY serait *WET* (Write Everything Twice ou We Enjoy Typing, qu'on peut traduire par Tout écrire en double ou On aime taper au clavier).
+
+En pratique, si vous avez la même information dans deux (ou plus) endroits, vous pouvez utiliser DRY pour les fusionner et réutiliser cette unique instance partout où c'est nécessaire.
+
+Voir aussi :
+
+- [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+
+### Principe KISS
+
+[KISS sur Wikipedia](https://fr.wikipedia.org/wiki/Principe_KISS)
+
+> Keep it simple, stupid. (Ne complique pas les choses)
+
+Le principe KISS énonce que la plupart des systèmes fonctionnent mieux s'ils sont simples que compliqués. Par conséquent, la simplicité devrait être un but essentiel dans la conception et toute complexité inutile devrait être évité. Provenant de la marine Américaine en 1960, la phrase est attribuée à l'ingénieur Kelly Johnson.
+
+Le principe est exemplifié le mieux par l'histoire de Johnson qui donna à une équipe d'ingénieurs une poignée d'outils et le défi de concevoir un avion de chasse qui soit réparable par un mécanicien lambda, sur le terrain, en condition de combat avec ces outils uniquement. Le "supid" fait donc référence à la relation entre la manière dont les choses cassent et la sophistication des outils à disposition pour les réparer, et non aux capacités des ingénieurs eux-mêmes.
+
+Voir aussi :
+
+- [Loi de Gall](#loi-de-gall)
+
+### YAGNI
+
+[YAGNI sur Wikipedia](https://fr.wikipedia.org/wiki/YAGNI)
+
+Il s'agit d'un acronyme pour ***Y**ou **A**in't **G**onna **N**eed **I**t*. Que l'on peut traduire par: "vous n'en aurez pas besoin".
+
+> Implémentez les choses uniquement quand vous en avez réellement besoin et non quand vous pensez que vous en aurez besoin plus tard.
+> ([Ron Jeffries](https://twitter.com/RonJeffries)) (Co-fondateur de XP et auteur du livre "Extreme Programming Installed")
+
+Ce principe *d'Extreme Programming* (XP) suggère que les développeurs ne devraient implémenter que les fonctionnalités qui sont nécessaires immédiatement et éviter de tenter de prédire l'avenir en implémentant des fonctionnalités qui pourraient être nécessaires plus tard.
+
+Adhérer à ce principe devrait réduire la quantité de code inutilisé dans le codebase et permet d'éviter de passer du temps sur des fonctionnalités qui n'apportent rien.
+
+Voir aussi :
+
+- [À lire: Extreme Programming Installed](#a-lire)
+
+### Illusions de l'informatique distribuée
+
+[Illusions de l'informatique distribuée sur Wikipedia](https://fr.wikipedia.org/wiki/Illusions_de_l%27informatique_distribu%C3%A9e)
+
+Aussi connues sous le nom de *illusions de l'informatique en réseau*, les illusions sont une liste de suppositions (ou croyances) concernant l'informatique distribuée, qui peuvent amener à des problèmes dans le développement logiciel. Les suppositions sont :
+
+- Le réseau est fiable
+- Le temps de latence est nul
+- La bande passante est infinie
+- Le réseau est sûr
+- La topologie du réseau ne change pas
+- Il y a un et un seul administrateur réseau
+- Le coût de transport est nul
+- Le réseau est homogène
+
+Les quatre premiers éléments furent listés par [Bill Joy](https://en.wikipedia.org/wiki/Bill_Joy) et [Tom Lyon](https://twitter.com/aka_pugs) vers 1991 et qualifiés pour la première fois d'"illusions de l'informatique distribuée" par [James Gosling](https://en.wikipedia.org/wiki/James_Gosling). [L. Peter Deutsch](https://en.wikipedia.org/wiki/L._Peter_Deutsch) ajouta les 5ème, 6ème et 7ème illusions. Gosling ajouta la 8ème illusion vers la fin des années 90.
+
+Le groupe était inspiré par ce qui se passait à l'époque chez [Sun Microsystems](https://en.wikipedia.org/wiki/Sun_Microsystems).
+
+Ces illusions devraient être gardées à l'esprit pour concevoir du code résistant étant donné que chacune d'entre elle peut mener à une perception biaisée qui ne prend pas en compte la réalité et la complexité des systèmes distribués.
+
+Voir aussi :
+
+- [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)
+- [Deutsch's Fallacies, 10 Years After](http://java.sys-con.com/node/38665)
+
+## À lire
+
+Si vous avez trouvé ces concepts intéressants, vous apprécierez peut être aussi les livres suivants :
+
+- [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Couvre les principes fondamentaux de l'Extreme Programming.
+- [The Mythical Man Month - Frederick P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - Un classique sur le développement logiciel. La [loi de Brooks](#loi-de-brooks) est un thème central du livre.
+- [Gödel, Escher, Bach: An Eternal Golden Braid - Douglas R. Hofstadter.](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - Un livre difficile à classe. La [loi de Hofstadter](#loi-de-hofstadter) est tirée de ce livre.
+- [The Dilbert Principle - Scott Adams](https://www.goodreads.com/book/show/85574.The_Dilbert_Principle) - Un regard humoristique sur l'Amérique corporate, par l'auteur du [principle de Dilbert](#principe-de-dilbert).
+- [The Peter Principle - Lawrence J. Peter](https://www.goodreads.com/book/show/890728.The_Peter_Principle) - Un autre regard humoristique porté sur les challenges du management et des grandes entreprises. L'origine du [principe de Peter](#principe-de-peter).
+
+## Traductions
+
+Grâce à l'aide de merveilleux contributeurs, Hacker Laws est disponible dans plusieurs langues. N'hésitez pas à envisager de sponsoriser les modérateurs !
+
+Langue | Moderateur | Status
+--- | --- | ---
+[🇧🇷 Brasileiro / Brésilien](./translations/pt-BR.md) | [Leonardo Costa](https://github.com/leofc97) | [![gitlocalized ](https://gitlocalize.com/repo/2513/pt-BR/badge.svg)](https://gitlocalize.com/repo/2513/pt-BR?utm_source=badge)[](https://gitlocalize.com/repo/2513/pt-BR?utm_source=badge)[](https://gitlocalize.com/repo/2513/pt-BR?utm_source=badge)
+[🇨🇳 中文 / Chinois](https://github.com/nusr/hacker-laws-zh) | [Steve Xu](https://github.com/nusr) | Partiellement complète
+[🇩🇪 Deutsch / Allemand](./translations/de.md) | [Vikto](https://github.com/viktodergunov) | [![gitlocalized ](https://gitlocalize.com/repo/2513/de/badge.svg)](https://gitlocalize.com/repo/2513/de?utm_source=badge)[](https://gitlocalize.com/repo/2513/de?utm_source=badge)[](https://gitlocalize.com/repo/2513/de?utm_source=badge)
+[🇫🇷 Français / French](./translations/fr.md) | [Kevin Bockelandt](https://github.com/KevinBockelandt) | [![gitlocalized ](https://gitlocalize.com/repo/2513/fr/badge.svg)](https://gitlocalize.com/repo/2513/fr?utm_source=badge)[](https://gitlocalize.com/repo/2513/fr?utm_source=badge)[](https://gitlocalize.com/repo/2513/fr?utm_source=badge)
+[🇬🇷 ελληνικά / Grecque](./translations/el.md) | [Panagiotis Gourgaris](https://github.com/0gap) | [![gitlocalized ](https://gitlocalize.com/repo/2513/el/badge.svg)](https://gitlocalize.com/repo/2513/el?utm_source=badge)[](https://gitlocalize.com/repo/2513/el?utm_source=badge)[](https://gitlocalize.com/repo/2513/el?utm_source=badge)
+[🇮🇹 Italiano / Italien](https://github.com/csparpa/hacker-laws-it) | [Claudio Sparpaglione](https://github.com/csparpa) | Partiellement complète
+[🇰🇷 한국어 / Coréen](https://github.com/codeanddonuts/hacker-laws-kr) | [Doughnut](https://github.com/codeanddonuts) | Partiellement complète
+[🇱🇻 Latviešu Valoda / Letton](./translations/lv.md) | [Arturs Jansons](https://github.com/iegik) | [![gitlocalized ](https://gitlocalize.com/repo/2513/lv/badge.svg)](https://gitlocalize.com/repo/2513/lv?utm_source=badge)[](https://gitlocalize.com/repo/2513/lv?utm_source=badge)[](https://gitlocalize.com/repo/2513/lv?utm_source=badge)
+[🇷🇺 Русская версия / Russe](https://github.com/solarrust/hacker-laws) | [Alena Batitskaya](https://github.com/solarrust) | Partiellement complète
+[🇪🇸 Castellano / Espagnol](./translations/es-ES.md) | [Manuel Rubio](https://github.com/manuel-rubio) ([Sponsor](https://github.com/sponsors/manuel-rubio)) | Partiellement complète
+[🇹🇷 Türkçe / Turc](https://github.com/umutphp/hacker-laws-tr) | [Umut Işık](https://github.com/umutphp) | [![gitlocalized ](https://gitlocalize.com/repo/2513/tr/badge.svg)](https://gitlocalize.com/repo/2513/tr?utm_source=badge)[](https://gitlocalize.com/repo/2513/tr?utm_source=badge)[](https://gitlocalize.com/repo/2513/tr?utm_source=badge)
+
+Si vous souhaitez mettre à jour une traduction, vous pouvez [ouvrir une pull request](https://github.com/dwmkerr/hacker-laws/pulls). Si vous voulez ajouter une nouvelle langue, connectez vous à [GitLocalize](https://gitlocalize.com/) pour créer un compte, puis créez une issue afin que je vous ajoute au projet ! Il serait également très apprécié d'ouvrir une pull request correspondante qui met à jour le tableau ci-dessus et la liste de liens au début de ce fichier.
+
+## Projets liés
+
+- [Tip of the Day](https://tips.darekkay.com/html/hacker-laws-en.html) - Recevez quotidiennement une loi / principe.
+
+## Contribuer
+
+N'hésitez pas à contribuer ! Vous pouvez [créer une issue](https://github.com/dwmkerr/hacker-laws/issues/new) pour suggérer une addition ou un changement, ou [ouvrir une pull request](https://github.com/dwmkerr/hacker-laws/compare) pour proposer vos propres modifications.
+
+Merci de lire le [guide de contribution](./.github/contributing.md) pour connaitre les pré-requis concernant le style, le contenu, etc. Veuillez lire également le [code de conduite](./.github/CODE_OF_CONDUCT.md) afin de le respecter lors des discussions sur le projet.
+
+## TODO
+
+Si vous êtes atteris ici vous avez cliqué sur un lien concernant un sujet qui n'a pas encore été rédigé. Désolé ! Tout n'est pas encore terminé.
+
+N'hésitez pas à [créer une issue](https://github.com/dwmkerr/hacker-laws/issues) pour avoir plus de détails, ou [ouvrez une pull request](https://github.com/dwmkerr/hacker-laws/pulls) pour soumettre votre propre texte sur le sujet.

translations/id.md

@@ -0,0 +1,783 @@
+# 💻📖 Undang Undang Peretas
+
+[![gitlocalized](https://gitlocalize.com/repo/2513/whole_project/badge.svg)](https://gitlocalize.com/repo/2513/whole_project?utm_source=badge)
+
+Hukum, Teori, Prinsip dan Pola yang berguna bagi pengembang (developer).
+
+- 🇨🇳 [中文 / Chinese Version](https://github.com/nusr/hacker-laws-zh) - Terima kasih kepada [Steve Xu](https://github.com/nusr)!
+- 🇮🇹 [Traduzione in Italiano](https://github.com/dwmkerr/hacker-laws/blob/master/translations/it-IT.md) - Terima kasih kepada [Claudio Sparpaglione](https://github.com/csparpa)!
+- 🇰🇷 [한국어 / Korean Version](https://github.com/codeanddonuts/hacker-laws-kr) - Terima kasih kepada [Doughnut](https://github.com/codeanddonuts)!
+- 🇷🇺 [Русская версия / Russian Version](https://github.com/solarrust/hacker-laws) - Terima kasih kepada [Alena Batitskaya](https://github.com/solarrust)!
+- 🇹🇷 [Türkçe / Turkish Version](https://github.com/umutphp/hacker-laws-tr) - Terima kasih kepada [Umut Işık](https://github.com/umutphp)
+- 🇧🇷 [Brasileiro / Brazilian Version](./translations/pt-BR.md) - Terima kasih kepada [Leonardo Costa](https://github.com/LeoFC97)
+- 🇪🇸 [Castellano / Spanish Version](./translations/es-ES.md) - Terima kasih kepada [Manuel Rubio](https://github.com/manuel-rubio)
+
+Suka dengan project ini? Silahkan Mempertimbangkan untuk [Mensponsori saya](https://github.com/sponsors/dwmkerr)!
+
+---
+
+<!-- vim-markdown-toc GFM -->
+
+* [Pendahuluan](#pendahuluan)
+* [Undang Undang](#undang-undang)
+    * [Hukum Amdahl](#hukum-amdahl)
+    * [Teori Windows Rusak](#teori-windows-rusak)
+    * [Hukum Brooks](#hukum-brook)
+    * [Hukum Conway](#hukum-conway)
+    * [Hukum Cunningham](#hukum-cunningham)
+    * [Nomor Dunbar](#nomor-dunbar)
+    * [Hukum Gall](#hukum-gall)
+    * [Hukum Goodhart](#hukum-goodhart)
+    * [Pisau Cukur Hanlon](#pisau-cukur-hanlon)
+    * [Hukum Hofstadter](#hukum-hofstadter)
+    * [Hukum Hutber](#hukum-hutber)
+    * [Siklus Hype & Hukum Amara](#sirklus-hype-dan-hukum-amara)
+    * [Hukum Hyrum (Hukum Antarmuka Implisit)](#hukum-hyrum-hukum-antarmuka-implisit)
+    * [Hukum Kernighan](#hukum-kernighan)
+    * [Hukum Metcalfe](#hukum-metcalfe)
+    * [Hukum Moore](#hukum-moore)
+    * [Hukum Murphy / Hukum Sod](#hukum-murphy)
+    * [Pisau Cukur Occam](#pisau-cukup-occam)
+    * [Hukum Parkinson](#hukum-parkinson)
+    * [Efek Optimalisasi Prematur](#efek-optimasi-prematur)
+    * [Hukum Putt](#hukum-putt)
+    * [Hukum Reed](#hukum-reed)
+    * [Hukum Konservasi Kompleksitas (Hukum Tesler)](#hukum-konservasi-kompleksitas-hukum-tesler)
+    * [Hukum Abstraksi Kebocoran](#hukum-abstraksi-kebocoran)
+    * [Hukum Triviality](#hukum-triviality)
+    * [Filsafat Unix](#filsafat-unix)
+    * [Model Spotify](#model-spotify)
+    * [Hukum Wadler](#hukum-wadler)
+    * [Hukum Wheaton](#hukum-gandum)
+* [Prinsip](#prinsip)
+    * [Prinsip Dilbert](#prinsip-dilbert)
+    * [Prinsip Pareto (Aturan 80/20)](#prinsip-pareto-aturan-8020)
+    * [Prinsip Peter](#prinsip-peter)
+    * [Prinsip Robustness (Hukum Postel)](#prinsip-robustness-princihukumple-postel)
+    * [SOLID](#solid)
+    * [Prinsip Tanggung Jawab Tunggal](#prinsip-tanggung-jawab-tunggal)
+    * [Prinsip Terbuka / Tertutup](#prinsip-terbukatertutup)
+    * [Prinsip Substitusi Liskov](#prinsip-substitusi-liskov)
+    * [Prinsip Segregasi Antarmuka](#prinsip-segregasi-antarmuka)
+    * [Prinsip Ketergantungan Inversi](#prinsip-ketergantungan-inversi)
+    * [Prinsip KERING](#prinsip-kering)
+    * [Prinsip KISS](#prinsip-kiss)
+    * [YAGNI](#yagni)
+    * [Kekeliuran Komputasi Terdistribusi](#kekeliuran-komputasi-terdistribusi)
+* [Daftar Bacaan](#daftar-bacaan)
+* [Berkontribusi](#berkontribusi)
+* [TODO](#todo)
+
+<!-- vim-markdown-toc -->
+
+## Pendahuluan
+
+Ada banyak undang-undang yang dibahas orang ketika berbicara tentang pembangunan. Repositori ini adalah referensi dan gambaran umum dari beberapa yang paling umum. Silakan bagikan dan kirimkan PR!
+
+❗: Repo ini berisi penjelasan tentang beberapa undang-undang, prinsip, dan pola, tetapi tidak _advokasi_ untuk salah satu dari mereka. Apakah mereka harus diterapkan akan selalu menjadi masalah perdebatan, dan sangat tergantung pada apa yang sedang Anda kerjakan.
+
+## Undang-undang
+
+Dan ini dia!
+
+### Hukum Amdahl
+
+[Hukum Amdahl di Wikipedia](https://en.wikipedia.org/wiki/Amdahl%27s_law)
+
+> Hukum Amdahl adalah formula yang menunjukkan _kecepatan potensial_ dari tugas komputasi yang dapat dicapai dengan meningkatkan sumber daya suatu sistem. Biasanya digunakan dalam komputasi paralel, ia dapat memprediksi manfaat secara aktual dari peningkatan jumlah prosesor, yang dibatasi oleh kemampuan program yang paralel.
+
+Ilustrasikan terbaik dengan sebuah contoh. Jika suatu program terdiri dari dua bagian, bagian A, yang harus dijalankan oleh satu prosesor, dan bagian B, yang dapat diparalelkan, maka jika kita melihat ketika menambahkan beberapa prosesor ke sistem yang menjalankan program maka hanya dapat memiliki manfaat yang terbatas. Ini berpotensi dapat sangat meningkatkan kecepatan bagian B - tetapi kecepatan bagian A akan tetap tidak berubah.
+
+Diagram di bawah ini menunjukkan beberapa contoh peningkatan kecepatan potensial:
+
+<img width="480px" alt="Diagram: Amdahl's Law" src="./../images/amdahls_law.png" />
+
+*(Gambar referensi: Oleh Daniels220 di Wikipedia Bahasa Inggris, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)*
+
+Seperti dapat dilihat, bahkan sebuah program yang parallelisable 50% akan mendapat manfaat sangat sedikit di luar 10 unit pemrosesan, sedangkan program yang 95% parallelisable masih dapat mencapai peningkatan kecepatan yang signifikan dengan lebih dari seribu unit pemrosesan.
+
+Karena [Hukum Moore](#hukum-moore) melambat, dan akselerasi kecepatan prosesor individu melambat, parallelisation adalah kunci untuk meningkatkan kinerja. Pemrograman grafik adalah contoh yang sangat baik - dengan komputasi berbasis Shader modern, piksel atau fragmen individual dapat diterjemahkan secara paralel - inilah sebabnya modern graphics cards sering memiliki ribuan inti pemrosesan (GPU atau Unit Shader).
+
+Lihat juga:
+
+- [Hukum Brook](#hukum-brook)
+- [Hukum Moore](#hukum-moore)
+
+### Teori Windows Rusak
+
+[Teori Windows Rusak di Wikipedia](https://en.wikipedia.org/wiki/Broken_windows_theory)
+
+Teori Windows Rusak menunjukkan bahwa tanda-tanda kejahatan yang nyata (atau kurangnya kepedulian terhadap suatu lingkungan) mengarah pada kejahatan yang semakin serius (atau semakin memburuknya lingkungan).
+
+Teori ini telah diterapkan pada pengembangan perangkat lunak, menunjukkan bahwa kode kualitas yang buruk (atau [Utang Teknis](#TODO)) dapat mengarah pada persepsi bahwa upaya untuk meningkatkan kualitas dapat diabaikan atau diremehkan, sehingga mengarah pada kode kualitas yang lebih buruk lagi. Efek ini mengalir ke penurunan kualitas yang besar dari waktu ke waktu.
+
+Lihat juga:
+
+- [Hutang Teknis](#TODO)
+
+Contoh:
+
+- [The Pragmatic Programming: Software Entropy](https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy)
+- [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/)
+
+### Hukum Brooks
+
+[Hukum Brooks di Wikipedia](https://en.wikipedia.org/wiki/Brooks%27s_law)
+
+> Menambahkan sumber daya manusia ke proyek pengembangan perangkat lunak yang terlambat membuatnya nanti.
+
+Undang-undang ini menunjukkan bahwa dalam banyak kasus, upaya untuk mempercepat pengiriman proyek yang sudah terlambat, dengan menambah lebih banyak orang, akan membuat pengiriman lebih lambat. Brooks jelas bahwa ini adalah penyederhanaan yang berlebihan, namun, alasan umum adalah bahwa mengingat peningkatan waktu sumber daya baru dan overhead komunikasi, dalam jangka pendek langsung kecepatan berkurang. Selain itu, banyak tugas yang mungkin tidak dapat dibagi, yaitu mudah didistribusikan di antara lebih banyak sumber daya, yang berarti peningkatan kecepatan potensial juga lebih rendah.
+
+Ungkapan umum dalam persalinan "Sembilan wanita tidak bisa menghasilkan bayi dalam satu bulan" berhubungan dengan Hukum Brooks, khususnya, fakta bahwa beberapa jenis pekerjaan tidak dapat dibagi atau diparalelkan.
+
+Ini adalah tema sentral dari buku '[The Mythical Man Month](#daftar-bacaan)'.
+
+Lihat juga:
+
+- [Death March](#todo)
+- [Daftar Bacaan: The Mythical Man Month](#daftar-bacaan)
+
+### Hukum Brooks
+
+[Hukum Brooks di Wikipedia](https://en.wikipedia.org/wiki/Conway%27s_law)
+
+Undang-undang ini menyatakan bahwa batasan teknis suatu sistem akan mencerminkan struktur organisasi. Ini biasa disebut ketika melihat perbaikan organisasi, Hukum Brooks menyarankan bahwa jika organisasi terstruktur menjadi banyak unit kecil, terputus, perangkat lunak yang dihasilkannya akan. Jika suatu organisasi dibangun lebih di sekitar 'vertikal' yang berorientasi pada fitur atau layanan, sistem perangkat lunak juga akan mencerminkan hal ini.
+
+Lihat juga:
+
+- [Model Spotify](#model-spotify)
+
+### Hukum Cunningham
+
+[Hukum Cunningham di Wikipedia](https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham's_Law)
+
+> Cara terbaik untuk mendapatkan jawaban yang benar di Internet adalah tidak dengan mengajukan pertanyaan, itu untuk mengirim jawaban yang salah.
+
+Menurut Steven McGeady, Ward Cunningham menasihatinya pada awal 1980-an: "Cara terbaik untuk mendapatkan jawaban yang benar di Internet adalah tidak mengajukan pertanyaan, itu untuk mengirim jawaban yang salah." McGeady menjuluki Hukum Cunningham ini, meskipun Cunningham menyangkal kepemilikan menyebutnya "salah kutip." Meskipun awalnya merujuk pada interaksi di Usenet, undang-undang tersebut telah digunakan untuk menggambarkan cara kerja komunitas online lainnya (mis., Wikipedia, Reddit, Twitter, Facebook).
+
+Lihat juga:
+
+- [XKCD 386: "Duty Calls"](https://xkcd.com/386/)
+
+### Nomor Dunbar
+
+[Nomor Dunbar di Wikipedia](https://en.wikipedia.org/wiki/Dunbar%27s_number)
+
+"Nomor Dunbar adalah batasan kognitif yang disarankan untuk jumlah orang yang dengannya seseorang dapat mempertahankan hubungan sosial yang stabil — hubungan di mana seorang individu mengetahui siapa setiap orang dan bagaimana setiap orang berhubungan dengan setiap orang lainnya." Ada beberapa perbedaan pendapat tentang jumlah pastinya. "... [Dunbar] mengusulkan agar manusia dapat dengan nyaman mempertahankan hanya 150 hubungan yang stabil." Dia memasukkan nomor itu ke dalam konteks yang lebih sosial, "jumlah orang yang Anda tidak akan merasa malu untuk bergabung tanpa diundang untuk minum jika Anda kebetulan menabrak mereka di sebuah bar." Perkiraan angka umumnya berkisar antara 100 dan 250.
+
+Seperti hubungan stabil antara individu, hubungan pengembang dengan basis kode membutuhkan upaya untuk mempertahankan. Ketika dihadapkan dengan proyek-proyek besar yang rumit, atau kepemilikan banyak proyek, kami bersandar pada konvensi, kebijakan, dan model prosedur untuk menskalakan. Nomor Dunbar tidak hanya penting untuk diingat ketika kantor tumbuh, tetapi juga ketika menetapkan ruang lingkup untuk upaya tim atau memutuskan kapan suatu sistem harus berinvestasi dalam perkakas untuk membantu dalam pemodelan dan mengotomatisasi overhead logistik. Menempatkan nomor ke dalam konteks teknik, itu adalah jumlah proyek (atau kompleksitas dinormalisasi dari satu proyek) di mana Anda akan merasa yakin untuk bergabung dengan rotasi on-call untuk mendukung.
+
+Lihat juga:
+
+- [Hukum Conway](#Hukum-conway)
+
+### Hukum Gall
+
+[Hukum Gall di Wikipedia](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law)
+
+> Sebuah sistem kompleks yang berfungsi selalu ditemukan telah berevolusi dari sistem sederhana yang berfungsi. Sistem kompleks yang dirancang dari awal tidak pernah berfungsi dan tidak dapat ditambal untuk membuatnya berfungsi. Anda harus memulai dari awal dengan sistem sederhana yang berfungsi.
+>
+> ([John Gall](https://en.wikipedia.org/wiki/John_Gall_(author)))
+
+Hukum Gall menyiratkan bahwa upaya untuk _design_ sistem yang sangat kompleks cenderung gagal. Sistem yang sangat kompleks jarang dibangun dalam sekali jalan, tetapi malah berkembang dari sistem yang lebih sederhana.
+
+Contoh klasik adalah world-wide-web. Dalam kondisi saat ini, ini adalah sistem yang sangat kompleks. Namun, itu didefinisikan pada awalnya sebagai cara sederhana untuk berbagi konten antar institusi akademik. Itu sangat sukses dalam mencapai tujuan-tujuan ini dan berkembang menjadi lebih kompleks dari waktu ke waktu.
+
+Lihat juga:
+
+- [KISS (Keep It Simple, Stupid)](#prinsip-kiss)
+
+### Hukum Goodhart
+
+[Hukum Goodhart di Wikipedia](https://en.wikipedia.org/wiki/Goodhart's_law)
+
+> Setiap keteraturan statistik yang diamati akan cenderung runtuh begitu tekanan diberikan untuk tujuan kontrol.
+>
+> _Charles Goodhart_
+
+Juga biasa dirujuk sebagai:
+
+> Ketika suatu ukuran menjadi target, itu tidak lagi menjadi ukuran yang baik.
+>
+> _Marilyn Strathern_
+
+Undang-undang menyatakan bahwa optimasi yang digerakkan oleh tindakan dapat mengarah pada devaluasi hasil pengukuran itu sendiri. Seperangkat tindakan yang terlalu selektif ([KPI](https://en.wikipedia.org/wiki/Performance_indicator)) yang diterapkan secara membuta pada suatu proses menghasilkan efek yang terdistorsi. Orang-orang cenderung untuk mengoptimalkan secara lokal dengan "bermain-main" sistem untuk memenuhi metrik tertentu daripada memperhatikan hasil holistik dari tindakan mereka.
+
+Contoh dunia nyata:
+- Tes bebas-konfirmasi memenuhi ekspektasi cakupan kode, meskipun faktanya maksud metrik adalah untuk menciptakan perangkat lunak yang teruji dengan baik.
+- Skor kinerja pengembang ditunjukkan oleh jumlah baris yang dilakukan mengarah pada basis kode yang terlalu besar yang tidak dapat dibenarkan.
+
+Lihat juga:
+
+- [Hukum Goodhart: Bagaimana Mengukur Hal-Hal yang Salah Mendorong Perilaku Tidak bermoral](https://coffeeandjunk.com/goodharts-campbells-law/)
+- [Dilbert pada perangkat lunak bebas bug](https://dilbert.com/strip/1995-11-13)
+
+### Pisau Cukur Hanlon
+
+[Pisau Cukur Hanlon di Wikipedia](https://en.wikipedia.org/wiki/Hanlon%27s_razor)
+
+> Jangan mengaitkan dengan kedengkian yang dijelaskan dengan cukup oleh kebodohan.
+>
+> Robert J. Hanlon
+
+Prinsip ini menunjukkan bahwa tindakan yang menghasilkan hasil negatif bukanlah hasil dari niat buruk. Sebaliknya hasil negatif lebih cenderung dikaitkan dengan tindakan-tindakan dan / atau dampak yang tidak sepenuhnya dipahami.
+
+### Hukum Hofstadter
+
+[Hukum Hofstadter di Wikipedia](https://en.wikipedia.org/wiki/Hofstadter%27s_law)
+
+> Itu selalu memakan waktu lebih lama dari yang Anda harapkan, bahkan ketika Anda memperhitungkan Hukum Hofstadter.
+>
+> (Douglas Hofstadter)
+
+Anda mungkin mendengar undang-undang ini disebut ketika melihat perkiraan berapa lama sesuatu akan terjadi. Tampaknya disangkal dalam pengembangan perangkat lunak yang kita cenderung tidak pandai memperkirakan secara akurat berapa lama waktu yang diperlukan untuk menghasilkan.
+
+Ini dari buku '[Gödel, Escher, Bach: An Eternal Golden Braid](#daftar-bacaan)'.
+
+Lihat juga:
+
+- [Daftar Bacaan: Gödel, Escher, Bach: An Eternal Golden Braid](#daftar-bacaan)
+
+### Hukum Hutber
+
+[Hukum Hutber di Wikipedia](https://en.wikipedia.org/wiki/Hutber%27s_law)
+
+> Perbaikan berarti kemunduran.
+>
+> ([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber))
+
+Undang-undang ini menunjukkan bahwa perbaikan pada suatu sistem akan menyebabkan kerusakan pada bagian lain, atau akan menyembunyikan kemunduran lainnya, yang secara keseluruhan mengarah pada degradasi dari kondisi sistem saat ini.
+
+Sebagai contoh, penurunan latensi respons untuk titik akhir tertentu dapat menyebabkan peningkatan throughput dan masalah kapasitas lebih lanjut dalam aliran permintaan, yang mempengaruhi sub-sistem yang sama sekali berbeda.
+
+### Siklus Hype & Hukum Amara
+
+[Siklus Hype di Wikipedia](https://en.wikipedia.org/wiki/Hype_cycle)
+
+> Kita cenderung melebih-lebihkan efek teknologi dalam jangka pendek dan meremehkan efek dalam jangka panjang.
+>
+> (Roy Amara)
+
+Hype Siklus adalah representasi visual dari kegembiraan dan pengembangan teknologi dari waktu ke waktu, awalnya diproduksi oleh Gartner. Paling baik ditunjukkan dengan visual:
+
+![Siklus Hype](./../images/gartner_hype_cycle.png)
+
+*(Referensi Gambar: Oleh Jeremykemp di bahasa inggris Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)*
+
+Singkatnya, siklus ini menunjukkan bahwa biasanya ada ledakan kegembiraan di sekitar teknologi baru dan dampak potensialnya. Tim sering melompat ke teknologi ini dengan cepat, dan kadang-kadang merasa kecewa dengan hasilnya. Ini mungkin karena teknologinya belum cukup matang, atau aplikasi dunia nyata belum sepenuhnya terwujud. Setelah waktu tertentu, kemampuan teknologi meningkat dan peluang praktis untuk menggunakannya meningkat, dan tim akhirnya menjadi produktif. Kutipan Roy Amara meringkas ini dengan paling ringkas - "Kita cenderung melebih-lebihkan efek teknologi dalam jangka pendek dan meremehkan dalam jangka panjang".
+
+### Hukum Hyrum (Hukum Antarmuka Implisit)
+
+[Hukum Hyrum](http://www.hyrumslaw.com/)
+
+> Dengan jumlah pengguna API yang memadai,
+> tidak masalah apa yang Anda janjikan dalam kontrak:
+> semua perilaku yang dapat diamati dari sistem Anda
+> akan bergantung pada seseorang.
+>
+> (Hyrum Wright)
+
+Hukum Hyrum menyatakan bahwa ketika Anda memiliki jumlah konsumen yang cukup besar dari suatu API, semua perilaku API (bahkan mereka yang tidak didefinisikan sebagai bagian dari kontrak publik) pada akhirnya akan tergantung pada seseorang. Contoh sepele mungkin elemen non-fungsional seperti waktu respons API. Contoh yang lebih halus mungkin konsumen yang mengandalkan menerapkan regex ke pesan kesalahan untuk menentukan * jenis * kesalahan API. Sekalipun kontrak publik API tidak menyatakan apa-apa tentang isi pesan, mengindikasikan bahwa pengguna harus menggunakan kode kesalahan yang terkait, _beberapa_ pengguna  dapat menggunakan pesan tersebut, dan mengubah pesan pada dasarnya merusak API untuk para pengguna tersebut.
+
+Lihat juga:
+
+- [Hukum Abstraksi Kebocoran](#hukum-abstraksi-kebocoran)
+- [XKCD 1172](https://xkcd.com/1172/)
+
+### Hukum Kernighan
+
+> Debugging dua kali lebih sulit daripada menulis kode di tempat pertama. Karena itu, jika Anda menulis kode sepintar mungkin, Anda, menurut definisi, tidak cukup pintar untuk debug itu.
+>
+> (Brian Kernighan)
+
+Hukum Kernighan adalah nama untuk [Brian Kernighan](https://en.wikipedia.org/wiki/Brian_Kernighan) dan berasal dari kutipan dari buku Kernighan dan Plauger [The Elements of Programming Style](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style):
+
+> Semua orang tahu bahwa debugging dua kali lebih sulit daripada menulis sebuah program. Jadi, jika Anda sepintar ketika Anda menulisnya, bagaimana Anda akan men-debug-nya?
+
+Sementara hiperbolik, Hukum Kernighan berpendapat bahwa kode sederhana lebih disukai daripada kode kompleks, karena men-debug setiap masalah yang muncul dalam kode kompleks mungkin mahal atau bahkan tidak layak.
+
+Lihat juga:
+
+- [Prinsip KISS](#prinsip-kiss)
+- [Filsafat Unix](#filsafat-unix)
+- [Pisau Cukur Occam](#pisau-cukup-occam)
+
+### Hukum Metcalfe
+
+[Hukum Metcalfe di Wikipedia](https://en.wikipedia.org/wiki/Metcalfe's_law)
+
+> Dalam teori jaringan, nilai suatu sistem tumbuh sekitar kuadrat dari jumlah pengguna sistem.
+
+Undang-undang ini didasarkan pada jumlah kemungkinan koneksi berpasangan dalam suatu sistem dan terkait erat dengan [Hukum Reed](#hukum-reed). Odlyzko dan yang lainnya berpendapat bahwa Hukum Reed dan Hukum Metcalfe melebih-lebihkan nilai sistem dengan tidak memperhitungkan batas-batas kognisi manusia pada efek jaringan; lihat [Nomor Dunbar](#nomor-dunbar).
+
+Lihat juga:
+
+- [Hukum Reed](#hukum-reed)
+- [Nomor Dunbar](#nomor-dunbar)
+
+### Hukum Moore
+
+[Hukum Moore di Wikipedia](https://en.wikipedia.org/wiki/Moore%27s_law)
+
+> Jumlah transistor dalam sirkuit terintegrasi bertambah dua kali lipat setiap dua tahun.
+
+Sering digunakan untuk menggambarkan kecepatan di mana semikonduktor dan teknologi chip telah meningkat, prediksi Moore telah terbukti sangat akurat dari tahun 1970-an hingga akhir 2000-an. Dalam beberapa tahun terakhir, tren telah berubah sedikit, sebagian karena [keterbatasan fisik pada sejauh mana komponen dapat miniatur](https://en.wikipedia.org/wiki/Quantum_tunnelling). Namun, kemajuan dalam parallelisation, dan perubahan revolusioner yang berpotensi dalam teknologi semikonduktor dan komputasi kuantum dapat berarti bahwa Hukum Moore dapat terus berlaku selama beberapa dekade mendatang.
+
+### Hukum Murphy / Hukum Sod
+
+[Hukum Murphy di Wikipedia](https://en.wikipedia.org/wiki/Murphy%27s_law)
+
+> Apa pun yang bisa salah akan salah.
+
+Terkait dengan [Edward A. Murphy, Jr](https://en.wikipedia.org/wiki/Edward_A._Murphy_Jr.) _Hukum Murphy_ menyatakan bahwa jika ada sesuatu yang salah, itu akan salah.
+
+Ini adalah pepatah umum di kalangan pengembang. Terkadang hal tak terduga terjadi ketika mengembangkan, menguji, atau bahkan dalam produksi. Ini juga dapat dikaitkan dengan (lebih umum dalam bahasa Inggris Inggris) _Hukum Sod_:
+
+> Jika ada yang salah, itu akan terjadi, pada saat yang paling buruk.
+
+'Hukum' ini umumnya digunakan dalam bentuk komik. Namun, fenomena seperti [_Pastikan Konfirmasi_](#TODO) dan [_Seleksi Pemilu_](#TODO) dapat membuat orang mungkin terlalu menekankan hukum-hukum ini (sebagian besar waktu ketika sesuatu bekerja, mereka tidak diperhatikan, kegagalan namun lebih terlihat. dan menarik lebih banyak diskusi).
+
+Lihat juga:
+
+- [Confirmation Bias](#TODO)
+- [Selection Bias](#TODO)
+
+### Pisau Cukur Occam
+
+[Pisau Cukur Occam di Wikipedia](https://en.wikipedia.org/wiki/Occam's_razor)
+
+> Entitas tidak boleh dikalikan tanpa keharusan.
+>
+> William dari Ockham
+
+Pisau Cukur Occam mengatakan bahwa di antara beberapa solusi yang mungkin, solusi yang paling mungkin adalah solusi dengan jumlah konsep dan asumsi paling sedikit. Solusi ini adalah yang paling sederhana dan hanya menyelesaikan masalah yang diberikan, tanpa memperkenalkan kompleksitas yang tidak disengaja dan kemungkinan konsekuensi negatif.
+
+Lihat juga:
+
+- [YAGNI](#yagni)
+- [No Silver Bullet: Kompleksitas Terkadang dan Kompleksitas Esensial](https://en.wikipedia.org/wiki/No_Silver_Bullet)
+
+Contoh:
+
+- [Pengembangan Perangkat Lunak Lean: Menghilangkan Limbah](https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste)
+
+### Hukum Parkinson
+
+[Hukum Parkinson di Wikipedia](https://en.wikipedia.org/wiki/Parkinson%27s_law)
+
+> Pekerjaan mengembang untuk mengisi waktu yang tersedia untuk penyelesaiannya.
+
+Dalam konteks aslinya, UU ini didasarkan pada studi tentang birokrasi. Ini mungkin secara pesimis diterapkan pada inisiatif pengembangan perangkat lunak, teorinya adalah bahwa tim akan tidak efisien sampai tenggat waktu dekat, kemudian bergegas untuk menyelesaikan pekerjaan dengan tenggat waktu, sehingga membuat tenggat waktu yang sebenarnya agak sewenang-wenang.
+
+Jika hukum ini digabungkan dengan [Hukum Hofstadter](#hukum-hofstadter), sudut pandang yang lebih pesimistis tercapai - pekerjaan akan meluas untuk mengisi waktu yang tersedia untuk penyelesaiannya dan * masih lebih lama dari yang diharapkan *.
+
+Lihat juga:
+
+- [Hukum Hofstadter](#hukum-hofstadter)
+
+### Efek Optimalisasi Prematur
+
+[Optimalisasi Prematur di WikiWikiWeb](http://wiki.c2.com/?PrematureOptimization)
+
+> Optimalisasi Prematur adalah akar dari semua kejahatan.
+>
+> [(Donald Knuth)] (https://twitter.com/realdonaldknuth?lang=en)
+
+Dalam makalah Donald Knuth [Pemrograman Terstruktur Dengan Pergi Ke Pernyataan](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements), ia menulis: "Pemrogram menghabiskan banyak waktu memikirkan, atau mengkhawatirkan, kecepatan bagian nonkritis dari program mereka, dan upaya efisiensi ini sebenarnya memiliki dampak negatif yang kuat ketika debugging dan pemeliharaan dipertimbangkan. Kita harus melupakan efisiensi kecil, katakanlah sekitar 97% dari waktu: **Optimalisasi Prematur adalah akar dari semua kejahatan**. Namun kita seharusnya tidak melewatkan peluang kita dalam 3% kritis itu. "
+
+Namun, _Optimalisasi Prematur_ dapat didefinisikan (dalam istilah yang lebih sedikit dimuat) sebagai mengoptimalkan sebelum kita tahu bahwa kita perlu.
+
+### Hukum Putt
+
+[Hukum Putt di Wikipedia](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat)
+
+> Teknologi didominasi oleh dua jenis orang, mereka yang mengerti apa yang tidak mereka kelola dan mereka yang mengelola apa yang tidak mereka mengerti.
+
+Hukum Putt sering diikuti oleh Putt's Corollary:
+
+> Setiap hierarki teknis, pada waktunya, mengembangkan inversi kompetensi.
+
+Pernyataan-pernyataan ini menunjukkan bahwa karena berbagai kriteria seleksi dan tren dalam bagaimana kelompok mengatur, akan ada sejumlah orang yang terampil di tingkat kerja organisasi teknis, dan sejumlah orang dalam peran manajerial yang tidak menyadari kompleksitas dan tantangan dari pekerjaan yang mereka kelola. Ini bisa disebabkan oleh fenomena seperti [Prinsip Peter](#prinsip-peter) atau [Prinsip Dilbert](#prinsip-dilbert).
+
+Namun, harus ditekankan bahwa Hukum seperti ini adalah generalisasi yang luas dan dapat berlaku untuk jenis organisasi _some_, dan tidak berlaku untuk yang lain.
+
+Lihat juga:
+
+- [Prinsip Peter](#prinsip-peter)
+- [Prinsip Dilbert](#prinsip-dilbert)
+
+
+### Hukum Reed
+
+[Hukum Reed di Wikipedia](https://en.wikipedia.org/wiki/Reed's_law)
+
+> Utilitas jaringan besar, khususnya jaringan sosial, secara eksponensial dengan ukuran jaringan.
+
+Undang-undang ini didasarkan pada teori grafik, di mana skala utilitas sebagai jumlah sub-kelompok yang mungkin, yang lebih cepat dari jumlah peserta atau jumlah kemungkinan koneksi berpasangan. Odlyzko dan lainnya berpendapat bahwa Hukum Reed melebih-lebihkan utilitas sistem dengan tidak memperhitungkan batas-batas kognisi manusia pada efek jaringan; lihat [Nomor Dunbar](#nomor-dunbar).
+
+Lihat juga:
+
+- [Hukum Metcalfe](#hukum-metcalfe)
+- [Nomor Dunbar](#nomor-dunbar)
+
+### Hukum Konservasi Kompleksitas (Hukum Tesler)
+
+[Hukum Konservasi Kompleksitas di Wikipedia](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity)
+
+Hukum ini menyatakan bahwa ada sejumlah kompleksitas dalam suatu sistem yang tidak dapat dikurangi.
+
+Beberapa kompleksitas dalam suatu sistem adalah 'tidak disengaja'. Ini adalah konsekuensi dari struktur yang buruk, kesalahan, atau hanya pemodelan masalah yang buruk untuk dipecahkan. Kompleksitas yang tidak disengaja dapat dikurangi (atau dihilangkan). Namun, beberapa kompleksitas bersifat 'intrinsik' sebagai konsekuensi dari kompleksitas yang melekat pada masalah yang sedang dipecahkan. Kompleksitas ini dapat dipindahkan, tetapi tidak dihilangkan.
+
+Salah satu elemen yang menarik dari undang-undang ini adalah saran bahwa meskipun dengan menyederhanakan seluruh sistem, kompleksitas intrinsiknya tidak berkurang, tetapi dipindah-pindahkan ke pengguna_, yang harus berperilaku dengan cara yang lebih kompleks.
+
+### Hukum Abstraksi Kebocoran
+
+[Hukum Abstraksi Kebocoran on Joel on Software](https://www.joelonsoftware.com/2002/11/11/hukum-abstraksi-kebocoran/)
+
+> Semua abstraksi non-sepele, sampai taraf tertentu, bocor.
+>
+> ([Joel Spolsky](https://twitter.com/spolsky))
+
+Undang-undang ini menyatakan bahwa abstraksi, yang umumnya digunakan dalam komputasi untuk menyederhanakan bekerja dengan sistem yang rumit, dalam situasi tertentu akan 'membocorkan' elemen sistem yang mendasarinya, ini membuat abstraksi itu berperilaku dengan cara yang tidak terduga.
+
+Contoh mungkin memuat file dan membaca isinya. API sistem file adalah _abstraksi_ dari sistem kernel level bawah, yang merupakan abstraksi atas proses fisik yang berkaitan dengan perubahan data pada plat magnetik (atau memori flash untuk SSD). Dalam kebanyakan kasus, abstraksi memperlakukan file seperti aliran data biner akan berfungsi. Namun, untuk drive magnetik, membaca data secara berurutan akan * secara signifikan * lebih cepat daripada akses acak (karena peningkatan overhead kesalahan halaman), tetapi untuk drive SSD, overhead ini tidak akan hadir. Detail yang mendasarinya perlu dipahami untuk menangani kasus ini (misalnya, file indeks basis data disusun untuk mengurangi overhead akses acak), rincian implementasi 'kebocoran' abstrak yang mungkin perlu diperhatikan pengembang.
+
+Contoh di atas dapat menjadi lebih kompleks ketika abstraksi _lebih_ diperkenalkan. Sistem operasi Linux memungkinkan file diakses melalui jaringan tetapi direpresentasikan secara lokal sebagai file 'normal'. Abstraksi ini akan 'bocor' jika ada kegagalan jaringan. Jika pengembang memperlakukan file ini sebagai file 'normal', tanpa mempertimbangkan fakta bahwa mereka mungkin mengalami latensi dan kegagalan jaringan, solusinya akan bermasalah.
+
+Artikel yang menggambarkan undang-undang ini menunjukkan bahwa ketergantungan yang berlebihan pada abstraksi, dikombinasikan dengan pemahaman yang buruk tentang proses yang mendasarinya, sebenarnya membuat masalah yang dihadapi semakin kompleks dalam beberapa kasus.
+
+Lihat juga:
+
+- [Hukum Hyrum](#hukum-hyrum-hukum-antarmuka-implisit)
+
+Contoh dunia nyata:
+
+- [Photoshop Startup Lambat](https://forums.adobe.com/thread/376152) - masalah yang saya temui di masa lalu. Photoshop akan lambat untuk memulai, kadang-kadang membutuhkan waktu beberapa menit. Tampaknya masalah adalah pada saat startup membaca beberapa informasi tentang printer default saat ini. Namun, jika printer itu sebenarnya adalah printer jaringan, ini bisa memakan waktu yang sangat lama. The _abstraction_ dari printer jaringan yang disajikan ke sistem yang mirip dengan printer lokal menyebabkan masalah bagi pengguna dalam situasi konektivitas yang buruk.
+
+### Hukum Triviality
+
+[Hukum Triviality di Wikipedia](https://en.wikipedia.org/wiki/Law_of_triviality)
+
+Undang-undang ini menunjukkan bahwa kelompok akan memberikan lebih banyak waktu dan perhatian pada masalah-masalah sepele atau kosmetik daripada masalah yang serius dan substansial.
+
+Contoh fiksi umum yang digunakan adalah bahwa komite menyetujui rencana untuk pembangkit listrik tenaga nuklir, yang menghabiskan sebagian besar waktu mereka membahas struktur gudang sepeda, daripada desain yang jauh lebih penting untuk pembangkit listrik itu sendiri. Mungkin sulit untuk memberikan masukan berharga pada diskusi tentang topik yang sangat besar dan kompleks tanpa keahlian atau persiapan subjek tingkat tinggi. Namun, orang ingin dilihat sebagai kontribusi input berharga. Oleh karena itu, kecenderungan untuk memfokuskan terlalu banyak waktu pada perincian kecil, yang dapat dipikirkan dengan mudah, tetapi tidak selalu penting.
+
+Contoh fiksi di atas menyebabkan penggunaan istilah 'Bike Shedding' sebagai ungkapan untuk membuang-buang waktu pada detail sepele. Istilah terkait adalah '[Mencukur Yak](https://en.wiktionary.org/wiki/yak_shaving),' yang mengartikan aktivitas yang tampaknya tidak relevan yang merupakan bagian dari rantai panjang prasyarat untuk tugas utama.
+
+### Filsafat Unix
+
+[Filsafat Unix di Wikipedia](https://en.wikipedia.org/wiki/Unix_philosophy)
+
+Filsafat Unix adalah bahwa komponen perangkat lunak harus kecil, dan fokus pada melakukan satu hal tertentu dengan baik. Ini dapat membuatnya lebih mudah untuk membangun sistem dengan menyusun unit-unit kecil, sederhana, dan terdefinisi dengan baik, daripada menggunakan program-program multi-fungsi yang besar, kompleks, dan multi-guna.
+
+Praktik modern seperti 'Arsitektur Layanan Mikro' dapat dianggap sebagai penerapan undang-undang ini, di mana layanan kecil, fokus, dan melakukan satu hal spesifik, yang memungkinkan perilaku kompleks dapat terdiri dari blok bangunan sederhana.
+
+### Model Spotify
+
+[Model Spotify di Spotify Laboratorium](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/)
+
+Model Spotify adalah pendekatan terhadap tim dan struktur organisasi yang telah dipopulerkan oleh 'Spotify'. Dalam model ini, tim disusun berdasarkan fitur, bukan teknologi.
+
+Model Spotify juga mempopulerkan konsep Tribes, Guilds, Chapters, yang merupakan komponen lain dari struktur organisasi mereka.
+
+### Hukum Wadler
+
+[Hukum Wadler on wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law)
+
+> Dalam desain bahasa apa pun, total waktu yang dihabiskan untuk mendiskusikan fitur dalam daftar ini sebanding dengan dua yang diangkat pada kekuatan posisinya.
+>
+> 0. Semantik
+> 1. Sintaks
+> 2. Sintaks leksikal
+> 3. Sintaksis leksikal komentar
+>
+> (Singkatnya, untuk setiap jam yang dihabiskan untuk semantik, 8 jam akan dihabiskan untuk sintaksis komentar).
+
+Mirip dengan [Hukum Triviality] (# hukum-triviality), Hukum Wadler menyatakan apa ketika merancang suatu bahasa, jumlah waktu yang dihabiskan untuk struktur bahasa sangat tinggi dibandingkan dengan pentingnya fitur-fitur itu.
+
+Lihat juga:
+
+- [Hukum Triviality](#hukum-triviality)
+
+### Hukum Wheaton
+
+[Link](http://www.wheatonslaw.com/)
+
+[Hari Resmi](https://dontbeadickday.com/)
+
+> Jangan menjadi kontol.
+>
+> _Setelah Wheaton_
+
+Diciptakan oleh Wil Wheaton (Star Trek: The Next Generation, The Big Bang Theory), hukum yang sederhana, ringkas, dan kuat ini bertujuan untuk meningkatkan keharmonisan dan rasa hormat dalam organisasi profesional. Ini dapat diterapkan ketika berbicara dengan rekan kerja, melakukan tinjauan kode, menentang sudut pandang lain, mengkritik, dan secara umum, sebagian besar interaksi profesional yang dimiliki manusia satu sama lain.
+
+## Prinsip
+
+Prinsip umumnya lebih cenderung menjadi pedoman yang berkaitan dengan desain.
+
+### Prinsip Dilbert
+
+[Prinsip Dilbert di Wikipedia](https://en.wikipedia.org/wiki/Dilbert_principle)
+
+> Perusahaan cenderung secara sistematis mempromosikan karyawan yang tidak kompeten ke manajemen untuk mengeluarkan mereka dari alur kerja.
+>
+> _Scott Adams_
+
+Konsep manajemen yang dikembangkan oleh Scott Adams (pencipta strip komik Dilbert), Prinsip Dilbert terinspirasi oleh [Prinsip Peter](#prinsip-peter). Di bawah Prinsip Dilbert, karyawan yang tidak pernah kompeten dipromosikan ke manajemen untuk membatasi kerusakan yang dapat mereka lakukan. Adams pertama kali menjelaskan prinsip tersebut dalam artikel Wall Street Journal 1995, dan memperluasnya dalam buku bisnisnya tahun 1996, [Prinsip Dilbert](#daftar-bacaan).
+
+Lihat juga:
+
+- [Prinsip Peter](#prinsip-peter)
+- [Hukum Putt](#hukum-putt)
+
+### Prinsip Pareto (Aturan 80/20)
+
+[Prinsip Pareto di Wikipedia](https://en.wikipedia.org/wiki/Pareto_principle)
+
+> Sebagian besar hal dalam hidup tidak terdistribusi secara merata.
+
+Prinsip Pareto menyarankan bahwa dalam beberapa kasus, sebagian besar hasil berasal dari minoritas input:
+
+- 80% dari perangkat lunak tertentu dapat ditulis dalam 20% dari total waktu yang dialokasikan (sebaliknya, 20% tersulit dari kode membutuhkan 80% dari waktu)
+- 20% dari upaya menghasilkan 80% dari hasilnya
+- 20% dari pekerjaan menciptakan 80% dari pendapatan
+- 20% dari bug menyebabkan 80% dari crash
+- 20% dari fitur menyebabkan 80% dari penggunaan
+
+Pada tahun 1940-an insinyur Amerika-Rumania Dr. Joseph Juran, yang secara luas diakui sebagai bapak kendali mutu, [mulai menerapkan Prinsip Pareto untuk masalah kualitas](https://en.wikipedia.org/wiki/Joseph_M._Juran).
+
+Prinsip ini juga dikenal sebagai: Aturan 80/20, Hukum Beberapa Vital, dan Prinsip Faktor Sparsity.
+
+Contoh dunia nyata:
+
+- Pada tahun 2002 Microsoft melaporkan bahwa dengan memperbaiki 20% bug yang paling banyak dilaporkan, 80% kesalahan dan kerusakan terkait di windows dan office akan dihilangkan ([Referensi](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)).
+
+### Prinsip Peter
+
+[Prinsip Peter di Wikipedia](https://en.wikipedia.org/wiki/Peter_principle)
+
+> Orang-orang dalam hierarki cenderung naik ke "tingkat ketidakmampuan" mereka.
+>
+> _Laurence J. Peter_
+
+Sebuah konsep manajemen yang dikembangkan oleh Laurence J. Peter, Prinsip Peter mengamati bahwa orang yang pandai dalam pekerjaannya dipromosikan, sampai mereka mencapai tingkat di mana mereka tidak lagi sukses ("tingkat ketidakmampuan" mereka. Pada titik ini, sebagaimana mereka lebih senior, mereka cenderung dikeluarkan dari organisasi (kecuali mereka tampil sangat buruk) dan akan terus berada dalam peran yang memiliki sedikit keterampilan intrinsik, karena keterampilan asli mereka yang membuat mereka sukses belum tentu keterampilan yang diperlukan untuk pekerjaan baru mereka.
+
+Ini sangat menarik bagi para insinyur - yang awalnya memulai dalam peran teknis yang mendalam, tetapi sering memiliki jalur karier yang mengarah ke _mengelola_ insinyur lainnya - yang memerlukan keahlian yang berbeda secara mendasar.
+
+Lihat juga:
+
+- [Prinsip Dilbert](#prinsip-dilbert)
+- [Hukum Putt](#hukum-putt)
+
+### Prinsip Robustness (Hukum Postel)
+
+[Prinsip Robustness di Wikipedia](https://en.wikipedia.org/wiki/Robustness_principle)
+
+> Jadilah konservatif dalam apa yang Anda lakukan, menjadi liberal dalam apa yang Anda terima dari orang lain.
+
+Sering diterapkan dalam pengembangan aplikasi server, prinsip ini menyatakan bahwa apa yang Anda kirim ke orang lain harus seminimal dan sesesuaian mungkin, tetapi Anda harus bertujuan untuk memungkinkan input yang tidak sesuai jika dapat diproses.
+
+Tujuan dari prinsip ini adalah untuk membangun sistem yang kuat, karena mereka dapat menangani input yang terbentuk buruk jika maksudnya masih dapat dipahami. Namun, ada kemungkinan implikasi keamanan dari penerimaan input yang cacat, khususnya jika pemrosesan input tersebut tidak diuji dengan baik.
+
+Membiarkan input yang tidak sesuai, pada waktunya, dapat merusak kemampuan protokol untuk berevolusi karena implementator pada akhirnya akan bergantung pada kebebasan ini untuk membangun fitur mereka.
+
+Lihat juga:
+
+- [Hukum Hyrum](#hukum-hyrum-hukum-antarmuka-implisit)
+
+
+### SOLID
+
+Ini adalah akronim, yang mengacu pada:
+
+* S: [Prinsip Tanggung Jawab Tunggal](#prinsip-tanggung-jawab-tunggal)
+* O: [Prinsip Terbuka / Tertutup](#prinsip-terbukatertutup)
+* L: [Prinsip Substitusi Liskov](#prinsip-substitusi-liskov)
+* I: [Prinsip Segregasi Antarmuka](#prinsip-segregasi-antarmuka)
+* D: [Prinsip Ketergantungan Inversi](#prinsip-ketergantungan-inversi)
+
+Ini adalah Prinsip utama dalam [Pemrograman Berorientasi Objek](#todo). Prinsip Desain seperti ini harus dapat membantu pengembang membangun sistem yang lebih dapat dipelihara.
+
+### Prinsip Tanggung Jawab Tunggal
+
+[Prinsip Tanggung Jawab Tunggal di Wikipedia](https://en.wikipedia.org/wiki/Single_responsibility_principle)
+
+> Setiap modul atau kelas hanya memiliki satu tanggung jawab.
+
+Prinsip pertama '[SOLID](#solid)'. Prinsip ini menyarankan agar modul atau kelas harus melakukan satu hal dan satu hal saja. Dalam istilah yang lebih praktis, ini berarti bahwa satu perubahan kecil ke fitur program harus memerlukan perubahan dalam satu komponen saja. Misalnya, mengubah cara kata sandi divalidasi untuk kompleksitas harus memerlukan perubahan hanya dalam satu bagian dari program.
+
+Secara teoritis, ini harus membuat kode lebih kuat, dan lebih mudah untuk diubah. Mengetahui bahwa komponen yang sedang diubah memiliki tanggung jawab tunggal hanya berarti bahwa _percobaan_ perubahan itu harus lebih mudah. Dengan menggunakan contoh sebelumnya, mengubah komponen kompleksitas kata sandi seharusnya hanya dapat mempengaruhi fitur yang terkait dengan kompleksitas kata sandi. Mungkin akan jauh lebih sulit untuk mempertimbangkan dampak dari perubahan pada komponen yang memiliki banyak tanggung jawab.
+
+Lihat juga:
+
+- [Pemrograman Berorientasi Objek](#todo)
+- [SOLID](#solid)
+
+### Prinsip Terbuka / Tertutup
+
+[Prinsip Terbuka / Tertutup di Wikipedia](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle)
+
+> Entitas harus terbuka untuk ekstensi dan ditutup untuk modifikasi.
+
+Prinsip kedua '[SOLID](#solid)'. Prinsip ini menyatakan bahwa entitas (yang bisa berupa kelas, modul, fungsi, dan sebagainya) harus dapat memiliki perilakunya _diperpanjang_, tetapi bahwa perilaku mereka _ada_ seharusnya tidak dapat dimodifikasi.
+
+Sebagai contoh hipotetis, bayangkan sebuah modul yang mampu mengubah dokumen penurunan harga menjadi HTML. Jika modul dapat diperluas untuk menangani fitur penurunan harga yang baru diusulkan, tanpa memodifikasi internal modul, maka itu akan terbuka untuk ekstensi. Jika modul dapat _tidak_ dimodifikasi oleh konsumen sehingga sekarang fitur Markdown yang ada ditangani, maka akan ditutup _ untuk modifikasi.
+
+Prinsip ini memiliki relevansi khusus untuk Pemrograman Berorientasi Objek, di mana kita dapat mendesain objek agar mudah diperluas, tetapi akan menghindari mendesain objek yang dapat mengubah perilaku mereka saat ini dengan cara yang tidak terduga.
+
+Lihat juga:
+
+- [Pemrograman Berorientasi Objek](#todo)
+- [SOLID](#solid)
+
+### Prinsip Substitusi Liskov
+
+[Prinsip Substitusi Liskov di Wikipedia](https://en.wikipedia.org/wiki/Liskov_substitution_principle)
+
+> Seharusnya dimungkinkan untuk mengganti tipe dengan subtipe, tanpa merusak sistem.
+
+Yang ketiga dari Prinsip '[SOLID](#solid)'. Prinsip ini menyatakan bahwa jika suatu komponen bergantung pada suatu tipe, maka ia harus dapat menggunakan subtipe dari tipe itu, tanpa sistem gagal atau harus mengetahui detail dari apa subtipe itu.
+
+Sebagai contoh, bayangkan kita memiliki metode yang membaca dokumen XML dari struktur yang mewakili file. Jika metode ini menggunakan tipe file 'dasar', maka apa pun yang berasal dari 'file' harus dapat digunakan dalam fungsi tersebut. Jika 'file' mendukung pencarian secara terbalik, dan parser XML menggunakan fungsi itu, tetapi tipe turunan 'file jaringan' gagal ketika pencarian terbalik dicoba, maka 'file jaringan' akan melanggar prinsip.
+
+Prinsip ini memiliki relevansi khusus untuk Pemrograman Berorientasi Objek, di mana hierarki jenis harus dimodelkan dengan cermat untuk menghindari pengguna sistem yang membingungkan.
+
+Lihat juga:
+
+- [Pemrograman Berorientasi Objek](#todo)
+- [SOLID](#solid)
+
+### Prinsip Segregasi Antarmuka
+
+[Prinsip Segregasi Antarmuka di Wikipedia](https://en.wikipedia.org/wiki/Interface_segregation_principle)
+
+> Tidak ada klien yang harus dipaksa untuk bergantung pada metode yang tidak digunakannya.
+
+Prinsip keempat '[SOLID](#solid)'. Prinsip ini menyatakan bahwa konsumen suatu komponen tidak boleh bergantung pada fungsi-fungsi komponen yang sebenarnya tidak digunakannya.
+
+Sebagai contoh, bayangkan kita memiliki metode yang membaca dokumen XML dari struktur yang mewakili file. Itu hanya perlu membaca byte, bergerak maju atau mundur dalam file. Jika metode ini perlu diperbarui karena fitur yang tidak terkait dari perubahan struktur file (seperti pembaruan untuk model izin yang digunakan untuk mewakili keamanan file), maka prinsipnya telah dibatalkan. Akan lebih baik bagi file untuk mengimplementasikan antarmuka 'seekable-stream', dan bagi pembaca XML untuk menggunakannya.
+
+Prinsip ini memiliki relevansi khusus untuk Pemrograman Berorientasi Objek, di mana antarmuka, hierarki dan tipe abstrak digunakan untuk [meminimalkan kopling] (# todo) antara komponen yang berbeda. [Duck typing] (# todo) adalah metodologi yang menegakkan prinsip ini dengan menghilangkan antarmuka eksplisit.
+
+Lihat juga:
+
+- [Pemrograman Berorientasi Objek](#todo)
+- [SOLID](#solid)
+- [Duck Typing](#todo)
+- [Decoupling](#todo)
+
+### Prinsip Ketergantungan Inversi
+
+[Prinsip Ketergantungan Inversi di Wikipedia](https://en.wikipedia.org/wiki/Dependency_inversion_principle)
+
+> Modul tingkat tinggi tidak boleh bergantung pada implementasi tingkat rendah.
+
+Kelima Prinsip '[SOLID](#solid)'. Prinsip ini menyatakan bahwa komponen pengatur tingkat yang lebih tinggi tidak harus mengetahui rincian ketergantungannya.
+
+Sebagai contoh, bayangkan kita memiliki program yang membaca metadata dari situs web. Kami berasumsi bahwa komponen utama harus mengetahui tentang komponen untuk mengunduh konten halaman web, kemudian komponen yang dapat membaca metadata. Jika kita mempertimbangkan inversi dependensi, komponen utama hanya akan bergantung pada komponen abstrak yang dapat mengambil data byte, dan kemudian komponen abstrak yang dapat membaca metadata dari aliran byte. Komponen utama tidak akan tahu tentang TCP / IP, HTTP, HTML, dll.
+
+Prinsip ini rumit, karena dapat 'membalikkan' dependensi yang diharapkan dari suatu sistem (karenanya namanya). Dalam praktiknya, ini juga berarti bahwa komponen orkestrasi terpisah harus memastikan implementasi yang benar dari tipe abstrak yang digunakan (mis. Dalam contoh sebelumnya, _sesuatu_ masih harus memberikan komponen pembaca metadata menjadi pengunduh file HTTP dan pembaca tag meta HTML). Ini kemudian menyentuh pola seperti [Pembalikan Kontrol](#todo) dan [Ketergantungan Injeksi](#todo).
+
+See also:
+
+- [Pemrograman Berorientasi Objek](#todo)
+- [SOLID](#solid)
+- [Inversi Kontrol](#todo)
+- [Dependensi Injection](#todo)
+
+### Prinsip KERING
+
+[Prinsip KERING di Wikipedia](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)
+
+> Setiap pengetahuan harus memiliki representasi tunggal, tidak ambigu, otoritatif dalam suatu sistem.
+
+KERING adalah akronim untuk _Jangan Ulangi Diri Sendiri_. Prinsip ini bertujuan untuk membantu pengembang mengurangi pengulangan kode dan menyimpan informasi di satu tempat dan dikutip pada 1999 oleh Andrew Hunt dan Dave Thomas dalam buku [Pengembang Pragmatis](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+
+> Kebalikan dari KERING adalah _WET_ (Tulis Semuanya Dua Kali atau Kami Menikmati Mengetik).
+
+Dalam praktiknya, jika Anda memiliki informasi yang sama di dua (atau lebih) tempat berbeda, Anda dapat menggunakan KERING untuk menggabungkannya menjadi satu dan menggunakannya kembali di mana pun Anda inginkan / butuhkan.
+
+Lihat juga:
+
+- [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+
+### Prinsip KISS
+
+[KISS di Wikipedia](https://en.wikipedia.org/wiki/KISS_principle)
+
+> Tetap sederhana, bodoh
+
+Prinsip KISS menyatakan bahwa sebagian besar sistem bekerja paling baik jika dibuat sederhana daripada dibuat rumit; oleh karena itu, kesederhanaan harus menjadi tujuan utama dalam desain, dan kompleksitas yang tidak perlu harus dihindari. Berasal dari Angkatan Laut AS pada tahun 1960, frasa tersebut telah dikaitkan dengan insinyur pesawat terbang Kelly Johnson.
+
+Prinsipnya paling baik dicontohkan oleh kisah Johnson yang menyerahkan tim insinyur desain beberapa alat, dengan tantangan bahwa pesawat jet yang mereka desain harus diperbaiki oleh mekanik rata-rata di lapangan dalam kondisi pertempuran hanya dengan alat-alat ini. Oleh karena itu, "bodoh" mengacu pada hubungan antara cara barang pecah dan kecanggihan alat yang tersedia untuk memperbaikinya, bukan kemampuan para insinyur itu sendiri.
+
+Lihat juga:
+
+- [Hukum Gall](#hukum-gall)
+
+### YAGNI
+
+[YAGNI di Wikipedia](https://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it)
+
+Ini adalah akronim untuk _**Y**ou **A**in't **G**onna **N**eed **I**t_.
+
+> Selalu terapkan hal-hal ketika Anda benar-benar membutuhkannya, jangan pernah ketika Anda hanya memperkirakan bahwa Anda membutuhkannya.
+>
+> ([Ron Jeffries](https://twitter.com/RonJeffries)) (salah satu pendiri dan penulis buku XP "Extreme Programming Installed")
+
+Prinsip _Extreme Programming_ (XP) ini menyarankan pengembang seharusnya hanya mengimplementasikan fungsionalitas yang diperlukan untuk persyaratan segera, dan menghindari upaya untuk memprediksi masa depan dengan mengimplementasikan fungsionalitas yang mungkin diperlukan nanti.
+
+Mematuhi prinsip ini harus mengurangi jumlah kode yang tidak digunakan dalam basis kode, dan menghindari waktu dan usaha yang dihabiskan untuk fungsionalitas yang tidak membawa nilai.
+
+Lihat juga:
+
+- [Daftar Bacaan: Extreme Programming Installed](#daftar-bacaan)
+
+### Kekeliuran Komputasi Terdistribusi
+
+[Kekeliuran Komputasi Terdistribusi di Wikipedia](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing)
+
+Juga dikenal sebagai _Fallacies of Networked Computing_, Fallacy adalah daftar dugaan (atau kepercayaan) tentang komputasi terdistribusi, yang dapat menyebabkan kegagalan dalam pengembangan perangkat lunak. Asumsinya adalah:
+
+- Jaringannya andal
+- Latensi adalah nol
+- Bandwidth tidak terbatas
+- Jaringan aman
+- Topologi tidak berubah
+- Ada satu administrator
+- Biaya transportasi nol
+- Jaringannya homogen
+
+Empat item pertama didaftar oleh [Bill Joy](https://en.wikipedia.org/wiki/Bill_Joy) dan [Tom Lyon](https://twitter.com/aka_pugs) sekitar 1991 dan pertama diklasifikasikan oleh [James Gosling](https://en.wikipedia.org/wiki/James_Gosling) sebagai "Fallacy of Networked Computing". [L. Peter Deutsch](https://en.wikipedia.org/wiki/L._Peter_Deutsch) menambahkan fallacy ke-5, ke-6 dan ke-7. Di akhir tahun 90-an Gosling menambahkan kekeliruan ke-8.
+
+Kelompok itu terinspirasi oleh apa yang terjadi pada saat di dalam [Sun Microsystems](https://en.wikipedia.org/wiki/Sun_Microsystems).
+
+Kekeliruan ini harus dipertimbangkan dengan hati-hati ketika merancang kode yang tangguh; dengan asumsi salah satu dari kesalahan ini dapat menyebabkan cacat logika yang gagal untuk berurusan dengan realitas dan kompleksitas sistem terdistribusi.
+
+Lihat juga:
+
+- [Mencari Makan untuk Kekeliruan Komputasi Terdistribusi (Bagian 1) - Vaidehi Joshi di Medium](https://medium.com/baseds/foraging-for-the-fallacies-of-distributed-computing-part-1-1b35c3b85b53)
+- [Deutsch's Fallacies, 10 Years After](http://java.sys-con.com/node/38665)
+
+## Daftar Bacaan
+
+Jika Anda merasa konsep ini menarik, Anda dapat menikmati buku-buku berikut.
+
+- [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Covers the core Prinsip of Extreme Programming.
+- [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. [Hukum Brooks](#hukum-brooks) is a central theme of the book.
+- [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. [Hukum Hofstadter](#hukum-hofstadter) is from the book.
+- [Prinsip Dilbert - 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](#prinsip-dilbert).
+- [Prinsip Peter - Lawrence J. Peter](https://www.goodreads.com/book/show/890728.The_Peter_Principle) - Another comic look at the challenges of larger organisations dan people management, the source of [Prinsip Peter](#prinsip-peter).
+
+## Berkontribusi
+
+Silakan berkontribusi! [Angkat masalah](https://github.com/dwmkerr/hacker-laws/issues/new) jika Anda ingin menyarankan penambahan atau perubahan, atau [Open a pull request](https://github.com/dwmkerr/hacker-laws/compare) untuk mengusulkan perubahan Anda sendiri.
+
+Pastikan untuk membaca [Panduan Berkontribusi](./../.github/contributing.md) untuk persyaratan teks, gaya dan sebagainya. Harap perhatikan [Code of Conduct](./../.github/CODE_OF_CONDUCT.md) ketika terlibat dalam diskusi tentang proyek.
+
+## TODO
+
+Hai! Jika Anda mendarat di sini, Anda telah mengklik tautan ke topik yang belum saya tulis, maaf tentang ini - ini sedang dalam proses!
+
+Jangan ragu untuk [Mengangkat Masalah](https://github.com/dwmkerr/hacker-laws/issues) meminta lebih banyak detail, atau [Open a Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) untuk menyerahkan definisi topik yang Anda usulkan.

translations/jp.md

@@ -0,0 +1,816 @@
+# 💻📖 ハッカーの法則
+
+開発者が役に立つと思う法則、理論、原則、パターン。
+
+[翻訳](#翻訳): [🇧🇷](../translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇩🇪](../translations/de.md) [🇫🇷](../translations/fr.md) [🇬🇷](../translations/el.md) [🇮🇹](https://github.com/csparpa/hacker-laws-it) [🇱🇻](../translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](../translations/es-ES.md) [🇹🇷](https://github.com/umutphp/hacker-laws-tr) [JP](../translations/jp.md)
+
+このプロジェクトが気に入りましたか？ぜひ私と[翻訳者](#%E7%BF%BB%E8%A8%B3)を支援すること[ご検討ください。](https://github.com/sponsors/dwmkerr)
+
+---
+
+<!-- vim-markdown-toc GFM -->
+
+- [イントロダクション](#イントロダクション)
+- [法則](#法則)
+    - [90-9-1 原則(1％ルール)](#90-9-1-原則1ルール)
+    - [アムダールの法則](#アムダールの法則)
+    - [割れ窓理論](#割れ窓理論)
+    - [ブルックスの法則](#ブルックスの法則)
+    - [コンウェイの法則](#コンウェイの法則)
+    - [カニンガムの法則](#カニンガムの法則)
+    - [ダンバー数](#ダンバー数)
+    - [ゴールの法則](#ゴールの法則)
+    - [グッドハートの法則](#グッドハートの法則)
+    - [ハンロンの剃刀](#ハンロンの剃刀)
+    - [ホフスタッターの法則](#ホフスタッターの法則)
+    - [ハーバーの法則](#ハーバーの法則)
+    - [ハイプサイクルとアマラの法則](#ハイプサイクルとアマラの法則)
+    - [ハイラムの法則（暗黙のインターフェースの法則）](#ハイラムの法則暗黙のインターフェースの法則)
+    - [カーニガンの法則](#カーニガンの法則)
+    - [リーナスの法則](#リーナスの法則)
+    - [メトカーフの法則](#メトカーフの法則)
+    - [ムーアの法則](#ムーアの法則)
+    - [マーフィーの法則/ソッドの法則](#マーフィーの法則ソッドの法則)
+    - [オッカムの剃刀](#オッカムの剃刀)
+    - [パーキンソンの法則](#パーキンソンの法則)
+    - [早すぎる最適化](#早すぎる最適化)
+    - [パットの法則](#パットの法則)
+    - [リードの法則](#リードの法則)
+    - [複雑性保存の法則（テスラーの法則）](#複雑性保存の法則テスラーの法則)
+    - [漏れのある抽象化の法則](#漏れのある抽象化の法則)
+    - [パーキンソンの凡俗法則](#パーキンソンの凡俗法則)
+    - [UNIX哲学](#unix哲学)
+    - [Spotifyモデル](#spotifyモデル)
+    - [ワドラーの法則](#ワドラーの法則)
+    - [ウィートンの法則](ウィートンの法則)
+- [原則](#原則)
+    - [ディルバートの原理](#ディルバートの原理)
+    - [パレート原理（80/20ルール）](#パレート原理8020ルール)
+    - [ピーターの原則](#ピーターの原則)
+    - [堅牢性の原則（ポステルの法則）](#堅牢性の原則ポステルの法則)
+    - [SOLID](#solid)
+    - [単一責任の原則](#単一責任の原則)
+    - [開放/閉鎖原則](#開放閉鎖原則)
+    - [リスコフ代替原則](#リスコフの置換原則)
+    - [インターフェース分離の原則](#インターフェース分離の原則)
+    - [依存関係の逆転の原則](#依存性逆転の原則)
+    - [DRY原則](#dry原則)
+    - [KISS原則](#kissの原則)
+    - [YAGNI](#yagni)
+    - [分散コンピューティングの落とし穴](#分散コンピューティングの落とし穴)
+- [関連書籍](#関連書籍)
+- [翻訳](#翻訳)
+- [関連プロジェクト](#関連プロジェクト)
+- [貢献方法](#貢献方法)
+- [TODO](#todo)
+
+<!-- vim-markdown-toc -->
+
+## イントロダクション
+
+ソフトウェア開発の話をするときに話題にのぼる法則はたくさんありますよね。このレポジトリでは、その中でも最も一般的なものをリストアップしその概要を説明しています。ぜひ、シェアしたりプルリクエストしてください!
+
+❗: このリポジトリには、いくつかの法則や原則、パターンの説明が含まれていますが、このレポジトリはそれらを*推奨*するものではありません。適用すべきかどうかは、常に議論の余地がありますし、あなたが何に取り組んでいるかに大きく依存します。
+
+## 法則
+
+そして、ここからが本編!
+
+### 90-9-1 原則(1％ルール)
+
+[1%の法則-Wikipedia](https://ja.wikipedia.org/wiki/1%25%E3%81%AE%E6%B3%95%E5%89%87)
+
+90-9-1原則は、wikiのようなインターネットコミュニティ内では、参加者のうちコンテンツを閲覧しているだけの人が90%、コンテンツを編集や修正する人が9%、残りの1%がコンテンツを追加することを示唆しています。
+
+実際の例:
+
+- 4つのデジタルヘルスソーシャルネットワークの2014年の調査によると、上位1％が投稿の73％を作成し、次の9％が平均約25％の投稿を作成し、残りの90％が平均2％を作成するという結果が示されてます。（ [参考文献](https://www.jmir.org/2014/2/e33/) ）
+
+関連項目：
+
+- [パレートの法則](#パレート原理8020ルール)
+
+### アムダールの法則
+
+[アムダールの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%A0%E3%83%80%E3%83%BC%E3%83%AB%E3%81%AE%E6%B3%95%E5%89%87)
+
+> アムダールの法則とは、リソースを追加した場合に、*期待できる性能向上*の程度です。通常、並列コンピューティングで使用され、プログラムの並列性によって制限されるプロセッサの数を増やすことによる実際の利益を予測することができます。
+
+例を挙げて説明します。プログラムが、1つのプロセッサで実行されなければならないパートAと、並列化できるパートBの2つのパートで構成されている場合、プログラムを実行するシステムに複数のプロセッサを追加しても、限られた利益しか得られないことがわかります。パートBの速度を大幅に向上させることは可能ですが、パートAの速度は変わらないでしょう。
+
+下記の図は、並列度増加と期待する速度改善の例を示しています。
+
+<img width="480px" alt="Diagram: Amdahl's Law" src="../images/amdahls_law.png">
+
+*（画像参照：英語版ウィキペディアのDaniels220、クリエイティブコモンズの表示-継承3.0非移植、https：//en.wikipedia.org/wiki/File：AmdahlsLaw.svg）*
+
+このように、50%の並列化が可能なプログラムであっても、10個の演算処理装置を超えるとほとんど恩恵を受けませんが、95%の並列化が可能なプログラムであれば、1000個以上の演算処理装置でも大幅な速度向上を達成することができます。
+
+[ムーアの法則](#ムーアの法則)による性能向上が鈍化し、個々のプロセッサの処理速度の進化が遅くなると、並列化が性能向上の鍵となります。最新のシェーダベースのコンピューティングでは、個々のピクセルやフラグメントを並列にレンダリングすることができます。現代のグラフィックカードが何千もの処理コア（GPUやシェーダユニット）が搭載されている場合多い理由はこれです。
+
+関連項目：
+
+- [ブルックスの法則](#ブルックスの法則)
+- [ムーアの法則](#ムーアの法則)
+
+### 割れ窓理論
+
+[割れ窓理論-Wikipedia](https://ja.wikipedia.org/wiki/%E5%89%B2%E3%82%8C%E7%AA%93%E7%90%86%E8%AB%96)
+
+割れ窓理論は、目に見える犯罪の兆候（または環境整備の欠如）が、さらに深刻な犯罪（または環境のさらなる悪化）につながることを示唆しています。
+
+この理論はソフトウェア開発に応用されており、質の低いコード(または [技術的負債](#TODO))は、品質を向上させる努力を無視したり、過小評価したりするという認識につながり、その結果、さらに質の低いコードの生産につながることを示唆しています。この効果は、時間の経過とともに品質を大きく低下させることにつながります。
+
+関連項目:
+
+- [技術的負債](#TODO)
+
+例：
+
+- [実用的なプログラミング：ソフトウェアエントロピー](https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy)
+- [コーディングホラー：割れ窓理論](https://blog.codinghorror.com/the-broken-window-theory/)
+- [オープンソース：プログラミングの喜び-割れ窓理論](https://opensourceforu.com/2011/05/joy-of-programming-broken-window-theory/)
+
+### ブルックスの法則
+
+[ブルックスの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%96%E3%83%AB%E3%83%83%E3%82%AF%E3%82%B9%E3%81%AE%E6%B3%95%E5%89%87)
+
+> 遅延しているソフトウェア開発プロジェクトに人材を追加するとプロジェクトがさらに遅延する。
+
+この法則は、多くの場合、すでに遅れているプロジェクトを挽回させようとして、人的リソースを追加することで、プロジェクトが更に遅延することを示唆しています。ブルックスは、これが単純化しすぎであることを明らかにしていますが、一般的な推論としては、新しい人的リソースの立ち上げにかかる時間とコミュニケーションのオーバーヘッドを考えると、短期的には速度が低下するということです。また、多くのタスクは分割出来ないことがあり、リソース間で簡単にタスク分散されない可能性があり、期待するベロシティも得られなくなることを意味します。
+
+出産でよく言われる「9人の女性は1ヶ月で子作りができない」という言葉は、ブルックスの法則、特にある種のタスクは分割や並列化できないという事実に関連しています。
+
+これは、「 [人月の神話](#関連書籍) 」という本の中心的なテーマです。
+
+関連項目:
+
+- [デスマーチ](#todo)
+- [関連書籍：人月の神話](#関連書籍)
+
+### コンウェイの法則
+
+[コンウェイの法則 Wikipedia(英語版)](https://en.wikipedia.org/wiki/Conway%27s_law)
+
+この法則は、システムの技術的な境界線が組織の構造を反映することを示唆しています。組織の改善を検討する際によく参考にされますが、コンウェイの法則では、組織が多くの小さな切り離されたユニットに構造化されている場合、その組織が生成するソフトウェアも小さな切り離されたユニットに構造になること示唆しています。もし組織が機能やサービスを中心とした「縦割り」に構築されているならば、ソフトウェアシステムもこれを反映し縦割りになります。
+
+関連項目:
+
+- [Spotifyモデル](#spotifyモデル)
+
+### カニンガムの法則
+
+[カニンガムの法則 - Meta - Meta-Wiki - Wikimedia](https://meta.wikimedia.org/wiki/Cunningham%27s_Law/ja)
+
+> インターネット上で正解を得るための最良の方法は、質問をすることではなく、間違った答えを投稿することです。
+
+スティーブン・マクゲディによると、1980年代初頭にウォード・カニンガム氏が彼にこうアドバイスをしたそうです。「インターネットで正しい答えを得る最善の方法は、質問をすることではなく、間違った答えを投稿することだ」と。マクギーディはこれをカニンガムの法則と呼んでいますが、カニンガムはこの法則の所有権を否定しており、カニンガムはこれを「誤引用」と言っています。元々はUsenet上でのやりとりのこと指していたが、この法則は他のオンラインコミュニティ（例：Wikipedia、Reddit、Twitter、Facebook）の仕組みを説明するために使われてきました。
+
+関連項目:
+
+- [XKCD 386：「デューティコール」](https://xkcd.com/386/)
+
+### ダンバー数
+
+[ダンバー数-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%80%E3%83%B3%E3%83%90%E3%83%BC%E6%95%B0)
+
+「ダンバーの数は、安定した社会的関係を維持できる人の数に対する認知的制限の提案です。つまり、個人が各人が誰であるか、そして各個人と他のすべての人との関係を知っている関係です。」正確な数にはいくつかの意見の相違があります。 「... [ダンバー]は、人間が快適に維持できるのは150人の安定した関係だけであると提案しました。 "彼はその数をより社会的なコンテキストで説明しています、「もしあなたがバーで偶然出会って、その場で突然一緒に酒を飲むことになったとしても、気まずさを感じない人数」。この数は一般的に100人から250人と言われています。
+
+個人間の安定した関係と同様に、コードベースと開発者の関係を維持するには努力が必要です。大規模で複雑なプロジェクトに直面したとき、や多くのプロジェクトをかかえているとき、私たちは慣例やポリシー、モデル化された手順に頼ってスケールアップを図っています。ダンバーの数字は、オフィスが大きくなったときに心に留めておくことが重要であるだけでなく、チームの責任範囲を設定したり、システムがモデリングや理論的オーバーヘッドの自動化を支援するツールにいつ投資すべきかを決定するときにも重要です。この数字をエンジニアリングのコンテキストに当てはめると、オンコールローテーションに参加してサポートすることに自信を持てるプロジェクトの数（または単一プロジェクトの複雑さを正規化した数）です。
+
+関連項目:
+
+- [コンウェイの法則](#コンウェイの法則)
+
+### ゴールの法則
+
+[ゴールの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%82%B4%E3%83%BC%E3%83%AB%E3%81%AE%E6%B3%95%E5%89%87)
+
+> 動作する複雑なシステムは、必ず、動作していた単純なシステムから進化したものであることがわかります。ゼロから設計された複雑なシステムは決して動作しませんし、それを動作させるためにパッチを当てることもできません。機能するシンプルなシステムからやり直さなければなりません。
+> ([ジョン・ゴール(英語)](https://en.wikipedia.org/wiki/John_Gall_(author)))
+
+ゴール法則は、高度に複雑なシステムを*設計*しようとする試みが失敗する可能性が高いことを示唆している。高度に複雑なシステムが一度に構築されることはめったになく、より単純なシステムから進化するものです。
+
+典型的な例は、world-wide-webです。今日では、これは高度に複雑なシステムですが、しかし、当初は学術機関間でコンテンツを共有するためのシンプルな方法として定義されていました。その目標を達成することに成功し、時間の経過とともにより複雑なものへと進化していきました。
+
+関連項目:
+
+- [KISS (Keep It Simple, Stupid)](#kissの原則)
+
+### グッドハートの法則
+
+[グッドハートの法則-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Goodhart's_law)
+
+> 観察されたどのような統計的規則性も、管理する目的で圧力をかけると崩壊してしまう傾向があります。
+> *チャールズ・グッドハート*
+
+次のようにも一般的に参照されます：
+
+> 計測結果が目標になると、その計測自体が役に立たなくなります。
+> *マリリン・ストラザーン*
+
+この法則は、測定主導の最適化が測定結果自体の価値を下げることにつながる可能性があると述べています。プロセスに盲目的に適用された過度に選択的な一連の（ [KPI](https://en.wikipedia.org/wiki/Performance_indicator) ）は、歪んだ効果をもたらします。人々は、自分たちの行動の全体的な結果に注意を払うのではなく、特定のメトリックを満たすためにシステムを「ゲーム」することで部分的に最適化する傾向があります。
+
+実際の例：
+
+- 十分にテストされたソフトウェアを作成することがコードカバレッジ測定の意図であったにもかかわらず、アサートなしのテストはコードカバレッジの基準を満たしています。
+- コミットされた行数によって開発者を評価するとは、無駄に肥大化したコードベースを作成することに繋がります。
+
+関連項目:
+
+- [グッドハートの法則：間違ったものを測定することが不道徳な行動をどのように促進するか](https://coffeeandjunk.com/goodharts-campbells-law/)
+- [バグのないソフトウェアのディルバート](https://dilbert.com/strip/1995-11-13)
+
+### ハンロンの剃刀
+
+[ハンロンの剃刀-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%8F%E3%83%B3%E3%83%AD%E3%83%B3%E3%81%AE%E5%89%83%E5%88%80)
+
+> 無能で十分説明されることに悪意を見出すな。
+> ロバート・J・ハンロン
+
+この原則は、ネガティブな結果をもたらす行動は悪意の結果ではないことを示唆している。むしろネガティブな結果はそれらの行為や影響が完全に理解されていなかったことに起因する可能性が高い。
+
+### ホフスタッターの法則
+
+[ホフスタッターの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%80%E3%82%B0%E3%83%A9%E3%82%B9%E3%83%BB%E3%83%9B%E3%83%95%E3%82%B9%E3%82%BF%E3%83%83%E3%82%BF%E3%83%BC#%E3%83%9B%E3%83%95%E3%82%B9%E3%82%BF%E3%83%83%E3%82%BF%E3%83%BC%E3%81%AE%E6%B3%95%E5%89%87)
+
+> ホフスタッターの法則を考慮しても、いつも予想以上に時間がかかる。
+> （ダグラスホフスタッター）
+
+何かがどれくらいかかるかの見積もりを見るときに、この法則を聞いたことがあるかもしれません。ソフトウェア開発においては、納品にかかる時間を正確に見積もるのは人々はあまり得意ではない傾向にあります。
+
+これは「 [ゲーデル、エッシャー、バッハ：永遠の金色の三つ編み](#関連書籍) 」という本からの引用です。
+
+関連項目:
+
+- [関連書籍： ゲーデル、エッシャー、バッハ：永遠の金色の三つ編み](#関連書籍)
+
+### ハーバーの法則
+
+[ハーバーの法則Wikipedia(英語版)](https://en.wikipedia.org/wiki/Hutber%27s_law)
+
+> 改善とは劣化を意味します。
+> （ [パトリックハットバー-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Patrick_Hutber) ）
+
+この法則は、システムを改善しようとして、他の部分の劣化につながったり、または他の劣化を隠し、全体的にシステムが現在の状態から劣化につながることを示唆しています。
+
+例えば、特定のエンドポイントに対する応答遅延を減少させようとして、リクエストフローのさらに後フェーズのスループットやキャパシティの問題を増加させ、全く関係ないサブシステムに影響を与える可能性があります。
+
+### ハイプ・サイクルとアマラの法則
+
+[ハイプ・サイクル- Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%8F%E3%82%A4%E3%83%97%E3%83%BB%E3%82%B5%E3%82%A4%E3%82%AF%E3%83%AB)
+
+> テクノロジーの効果を短期的には過大評価し、長期的には過小評価する傾向がある。
+> （ロイ・アマラ）
+
+ハイプ・サイクルは、元々はガートナー社によって作成された、時間をかけてテクノロジーの興奮と発展を視覚的に表現したものです。視覚的に表示するのが最適です。
+
+![The Hype Cycle](../images/gartner_hype_cycle.png)
+
+*（画像参照：英語版ウィキペディアのJeremykemp著、CC BY-SA 3.0、https：//commons.wikimedia.org/w/index.php？curid = 10547051）*
+
+要するに、このサイクルは、一般的に新技術とその潜在的な影響力について興奮があることを示唆している。チームはしばしばこれらのテクノロジーにすぐに飛びつき、その結果に失望してしまうことがあります。これは、テクノロジーがまだ十分に成熟していなかったり、実世界でのアプリケーションがまだ十分に実現されていないからかもしれません。ある程度の時間が経つと、テクノロジーの能力が向上し、実際に使用する機会が増え、チームはようやく生産性を高めることができます。Roy Amaraのこの言葉は、このことを最も簡潔に要約しています。「私たちは、テクノロジーの効果を短期的には過大評価し、長期的には過小評価する傾向がある」。
+
+### ハイラムの法則（暗黙のインターフェースの法則）
+
+[ハイラムの法則(英語)](http://www.hyrumslaw.com/)
+
+> あるAPIに十分なユーザー数がいれば、契約書で何を約束するかどうかは問題ではありません。 あなたのシステムのすべての観測可能な動作は、誰かに依存することになります。
+> （ハイラム・ライト）
+
+ハイラムの法則では、APIの*ユーザ数が十分に多い*場合、APIのすべての動作(公的契約の一部として定義されていないものであっても)は、最終的に誰かに依存するようになるということを述べています。些細な例としては、APIの応答時間などの非機能要件が挙げられます。もっと微妙な例は、APIのエラーの*タイプ*を判断するために、エラーメッセージに正規表現を適用することに依存しているユーザかもしれません。API の公開契約ではメッセージの内容について何も記述されておらず、ユーザーがメッセージではなくエラーコードを使用すべきでと明示していたとしても、*一部の*ユーザーがそれを無視してメッセージを使用する可能性があり、メッセージを変更することでそのようなユーザーのための API が本質的に壊れてしまうことになります。
+
+関連項目:
+
+- [漏れのある抽象化の法則](#漏れのある抽象化の法則)
+- [XKCD 1172](https://xkcd.com/1172/)
+
+### カーニガンの法則
+
+> デバッギングはコーディングよりも2倍難しい。従って、あなたが可能な限り賢くコードを書くとしたら、定義からして、あなたはそれをデバッグできるほど賢くない。
+> （ブライアン・カーニハン）
+
+カーニガンの法則は、 [ブライアンカーニハンに](https://en.wikipedia.org/wiki/Brian_Kernighan)ちなんで名付けられ、カーニハンとプラウガーの著書[「Elements of Programming Style](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style) 」からの引用に基づいています。
+
+> デバッグは、そもそもプログラムを書くことの2倍大変だということは誰もが知っています。では、コードを書いた時に同じくらい賢いとしたら、どうやってデバッグするのでしょうか？
+
+双曲線的ではありますが、カーニガンの法則は、複雑なコードで発生した問題をデバッグするのはコストがかかるか、実現不可能な場合があるため、単純なコードは複雑なコードよりも優先されるべきであるということを言っています。
+
+関連項目:
+
+- [KISSの原則](#kissの原則)
+- [UNIX哲学](#unix哲学)
+- [オッカムのかみそり](#オッカムの剃刀)
+
+### リーナスの法則
+
+[リーナスの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%BC%E3%83%8A%E3%82%B9%E3%81%AE%E6%B3%95%E5%89%87)
+
+> 十分な目ん玉があれば、全てのバグは洗い出される。
+>
+> _エリック・S・レイモンド_
+
+この法則は簡単に言うと、あるプログラムを見る人が多ければ多いほど、誰かがその問題を以前に見て解決している可能性が高くなる、あるいはそれに非常に近い状況になる、というものです。
+
+元々はプロジェクトのオープンソースモデルの価値を説明するために使われましたが、どんなソフトウェアプロジェクトにも当てはまります。プロセスにも拡大して適用できます。より多くのコードレビューや静的解析、また多角的なテストプロセスによって、問題をより可視化されて識別しやすくなります。
+
+より格式ばって言うと以下のようになります。
+
+> ベータテスターと共同開発者が十分多くいれば、ほとんど全ての問題はすぐに明確になり、似た問題に以前遭遇したことのある人によって解決されるだろう。
+
+この法則は、エリック・S・レイモンドの著作『[伽藍とバザール](https://ja.wikipedia.org/wiki/%E4%BC%BD%E8%97%8D%E3%81%A8%E3%83%90%E3%82%B6%E3%83%BC%E3%83%AB)』の中で、[リーナス・トーバルズ](https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%BC%E3%83%8A%E3%82%B9%E3%83%BB%E3%83%88%E3%83%BC%E3%83%90%E3%83%AB%E3%82%BA)に敬意を表して名付けられました。
+
+### メトカーフの法則
+
+[メトカーフの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%A1%E3%83%88%E3%82%AB%E3%83%BC%E3%83%95%E3%81%AE%E6%B3%95%E5%89%87)
+
+> ネットワーク理論では、システムの価値は、システムの利用者数の約2乗で成長します。
+
+この法則は、システム内で可能なペアワイズ接続の数に基づいており、 [リードの法則](#リードの法則)と密接に関連しています。オドリズコらは、リードの法則とメトカーフの法則の両方が、ネットワーク効果に関する人間の認知の限界を考慮しないことによって、システムの価値を過大評価していると主張しています。 [ダンバー数を](#ダンバー数)参照してください。
+
+関連項目:
+
+- [リードの法則](#リードの法則)
+- [ダンバー数](#ダンバー数)
+
+### ムーアの法則
+
+[ムーアの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%A0%E3%83%BC%E3%82%A2%E3%81%AE%E6%B3%95%E5%89%87)
+
+> 集積回路のトランジスタ数は約2年ごとに倍増します。
+
+この法則は半導体やチップ技術の進歩の速さを示すためによく使われますが、ムーアの予測は1970年代から2000年代後半にかけて非常に正確であることが証明されています。近年では、その傾向はわずかに変化していますが、その理由の一部には[コンポーネントを小型化できる程度の物理的な制限(トンネル効果)](https://ja.wikipedia.org/wiki/%E3%83%88%E3%83%B3%E3%83%8D%E3%83%AB%E5%8A%B9%E6%9E%9C)があります。しかし、並列化の進歩や、半導体技術や量子コンピューティングにおける革命的な変化により、ムーアの法則が今後数十年にわたって真実であり続ける可能性があることを意味しています。
+
+### マーフィーの法則/ソッドの法則
+
+[マーフィーの法則-Wikipedia(](https://ja.wikipedia.org/wiki/%E3%83%9E%E3%83%BC%E3%83%95%E3%82%A3%E3%83%BC%E3%81%AE%E6%B3%95%E5%89%87)
+
+> 何をやってもうまくいかないものはうまくいかない。
+
+[エドワード・A・マーフィー・ジュニア](https://ja.wikipedia.org/wiki/%E3%82%A8%E3%83%89%E3%83%AF%E3%83%BC%E3%83%89%E3%83%BBA%E3%83%BB%E3%83%9E%E3%83%BC%E3%83%95%E3%82%A3%E3%83%BC%E3%83%BB%E3%82%B8%E3%83%A5%E3%83%8B%E3%82%A2)に関連して、*マーフィーの法則*では、物事がうまくいかないことがあれば、それはうまくいかないだろうということが述べられています。
+
+これは開発者の間でよくある格言です。開発中、テスト中、あるいは本番中にも予期せぬことが起こることがあります。これは、 *ソッドの法則* （イギリス英語ではより一般的）にも関連しています。
+
+> 何かがうまくいかないことがあれば、最悪のタイミングでそうなる。
+
+これらの「法則」は、一般的にコミカルな意味で使われています。ただし、 [*確証バイアス*](#TODO)や[*選択バイアス*](#TODO)などの現象は、人々がこれらの法則を強調しすぎてしまう可能性があります(物事がうまくいく時の大半は、彼らは気づかれないですが、失敗は、しかし、より顕著であり、より多くの議論を生みます)。
+
+関連項目:
+
+- [確証バイアス](#TODO)
+- [選択バイアス](#TODO)
+
+### オッカムの剃刀
+
+[オッカムの剃刀-Wikipedia](https://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%83%E3%82%AB%E3%83%A0%E3%81%AE%E5%89%83%E5%88%80)
+
+> エンティティは必要なくして掛け算してはいけない。
+> オッカムのウィリアム
+
+オッカムの剃刀は、いくつかの可能な解決策の中で、最も可能性の高い解決策は、概念と仮定の数が最も少ないものであると言います。この解は最も単純で、与えられた問題だけを解決し、偶発的な複雑さや起こりうる負の結果を導入することはありません。
+
+関連項目:
+
+- [YAGNI](#yagni)
+- [銀の弾などない：偶発的な複雑さと本質的な複雑さ](https://ja.wikipedia.org/wiki/%E9%8A%80%E3%81%AE%E5%BC%BE%E3%81%AA%E3%81%A9%E3%81%AA%E3%81%84)
+
+例:
+
+- [リーンソフトウェア開発：無駄をなくす-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste)
+
+### パーキンソンの法則
+
+[パーキンソンの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%91%E3%83%BC%E3%82%AD%E3%83%B3%E3%82%BD%E3%83%B3%E3%81%AE%E6%B3%95%E5%89%87)
+
+> 仕事の量は、与えられた時間を全て満たすまで膨張する。
+
+元の文脈では、この法則は官僚機構の研究に基づいていた。この法則は、ソフトウェア開発の取り組みに悲観的に適用されるかもしれません。理論的には、チームは締め切りが近づくまで非効率的であり、その後、締め切りまでに仕事を完成させようと急ぐので、実際の締め切りはやや恣意的になるということです。
+
+この法則が[ホフスタッターの法則](#ホフスタッターの法則)と組み合わされた場合、さらに悲観的な見方が得られます。作業は、その完了に利用できる時間を埋めるために拡大し*、予想よりも長くかかり*ます。
+
+関連項目:
+
+- [ホフスタッターの法則](#ホフスタッターの法則)
+
+### 早すぎる最適化
+
+[最適化する時期-Wikipedia](https://ja.wikipedia.org/wiki/%E6%9C%80%E9%81%A9%E5%8C%96_(%E6%83%85%E5%A0%B1%E5%B7%A5%E5%AD%A6)#%E6%9C%80%E9%81%A9%E5%8C%96%E3%81%99%E3%82%8B%E6%99%82%E6%9C%9F)
+
+> 早すぎる最適化は諸悪の根源です。
+> [（ドナルドクヌース）](https://twitter.com/realdonaldknuth?lang=en)
+
+Donald Knuthの論文「 [Structured Programming With Go To Statements」で](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements) 、彼は次のように書いています。「プログラマーは、プログラムの重要でない部分の速度について考えたり、心配したりして膨大な量の時間を浪費している。小さな効率性、つまり97%程度の効率性については忘れた方がいいでしょう。 **早すぎる最適化は諸悪の根源です** 。しかし、その重要な3％で機会を逃してはなりません。」
+
+しかし、 *早すぎる最適化*は（負荷の低い用語で）、必要性を知る前に最適化することと定義することができます。
+
+### パットの法則
+
+[パットの法則-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat)
+
+> 技術は、管理しないことを理解している人と、理解していないことを管理している人の2つのタイプに支配されている。
+
+よくパットの法則にはパットの帰結が続きます。
+
+> すべての技術的な階層は、時間の経過とともに、能力の逆転を発生させます。
+
+これらの記述は、グループがどのように組織化されるかという様々な選択基準や傾向のために、技術的な組織の実務レベルには熟練した人が多く、管理職には自分が管理している仕事の複雑さや課題を認識していない人が多くいることを示唆しています。これは[、ピーター原理](#ピーターの原則)や[ディルバート原理](#ディルバートの原理)などの現象が原因である可能性があります。
+
+ただし、このような法則は広範に一般化されており、*特定*の一部の組織には適用されますが、他の組織には適用されない場合があることを強調しておく必要があります。
+
+関連項目:
+
+- [ピーターの原則](#ピーターの原則)
+- [ディルバートの原理](#ディルバートの原理)
+
+### リードの法則
+
+[リードの法則-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Reed's_law)
+
+> 大規模ネットワーク、特にソーシャルネットワークの効用は、ネットワークの大きさに応じて指数関数的にスケーリングする。
+
+この法則はグラフ理論に基づいており、実用性は可能なサブグループの数に応じてスケールし、これは参加者の数や可能なペアワイズ接続の数よりも速くスケールします。オドリズコ氏らは、ネットワークの影響に対する人間の認識の限界を考慮しないことで、リードの法則がシステムの有用性を誇張していると主張しています。 [ダンバー数を](#ダンバー数)参照してください。
+
+関連項目:
+
+- [メトカーフの法則](#メトカーフの法則)
+- [ダンバー数](#ダンバー数)
+
+### 複雑性保存の法則（テスラーの法則）
+
+[The Law of Conservation of Complexity-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity)
+
+この法則では、システムには削減できない一定の複雑さがあるとされています。
+
+システムの複雑さの中には、「不注意」なものもあります。これは、構造の不備、ミス、または解決すべき問題のモデリングの不備の結果です。不注意な複雑さは、減らすことができます（または排除することができます）。しかし、いくつかの複雑さは、解決される問題に内在する複雑さの結果として「内在的」です。この複雑さは動かすことはできますが、排除することはできません。
+
+この法則の興味深い側面は、システム全体を単純化しても、本質的な複雑さは軽減されず、より複雑な方法でシステムを動かす*ユーザーに複雑性が移される*という提案です。
+
+### 漏れのある抽象化の法則
+
+[漏れのある抽象化の法則 Joel on Software(英語)](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/)
+
+> 自明でない抽象化はすべて、程度の差こそあれ、漏れがある。
+> （ [ジョエル・スポルスキー](https://twitter.com/spolsky) ）
+
+この法則では、複雑なシステムでの作業を簡略化するためにコンピューティングで一般的に使用される抽象化は、特定の状況では、基礎となるシステムの要素を「漏らし」、抽象化が予期しない方法で動作することになると述べています。
+
+例としては、ファイルをロードしてその内容を読むことが挙げられます。ファイルシステム API は低レベルのカーネルシステムの *抽象化*であり、それ自体が磁気プラッター (または SSD のフラッシュメモリ) 上のデータの変更に関連する物理的なプロセスを抽象化したものです。ほとんどの場合、ファイルをバイナリデータのストリームのように扱うという抽象化が機能します。磁気ドライブの場合、データを連続的に読み込むと、ランダム・アクセスよりも（ページ・フォルトのオーバーヘッドが増加するため）*大幅に*速くなりますが、SSD ドライブの場合は、このオーバーヘッドは存在しません。この場合に対処するためには、基本的な詳細を理解する必要があります（例えば、データベースのインデックスファイルはランダムアクセスのオーバーヘッドを減らすために構造化されています）が、抽象化された実装の詳細は、開発者が注意する必要があるかもしれません。
+
+上記の例は、より多くの抽象化が導入されると、*より*複雑になる可能性があります。Linux オペレーティングシステムでは、ネットワーク経由でファイルにアクセスすることができますが、ローカルでは「通常の」ファイルとして表現されます。この抽象化は、ネットワーク障害が発生した場合に「漏れ」ます。開発者がこれらのファイルをネットワークの遅延や障害の影響を受ける可能性があることを考慮せずに「通常の」ファイルとして扱ってしまうと、解決策がバグだらけになってしまいます。
+
+この法則を説明している記事によると、抽象化への過度の依存は、基礎となるプロセスの理解不足と相まって、実際には手元にある問題への対処を、場合によっては*より*複雑なものにしてしまうことが示唆されています。
+
+関連項目:
+
+- [ハイラムの法則](#ハイラムの法則暗黙のインターフェースの法則)
+
+実際の例：
+
+- [Photoshop Slow Startup](https://forums.adobe.com/thread/376152) - 過去に遭遇した問題 Photoshopの起動が遅く、数分かかることもありました。問題は、起動時に現在のデフォルトプリンタに関する情報を読み取ることだったようです。しかし、そのプリンタが実際にネットワークプリンタである場合、これは非常に長い時間がかかる可能性があります。ネットワークプリンタがローカルプリンタと同様に*抽象化*してしまったことにより接続時間の問題を引き起こしました。
+
+### パーキンソンの凡俗法則
+
+[パーキンソンの凡俗法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%91%E3%83%BC%E3%82%AD%E3%83%B3%E3%82%BD%E3%83%B3%E3%81%AE%E5%87%A1%E4%BF%97%E6%B3%95%E5%89%87)
+
+この法則は、グループが深刻で実質的なものよりも、些細な問題や表面上の問題にはるかに多くの時間と注意力を注ぐことを示唆しています。
+
+よくある架空の例は、原子力発電所の計画を承認する委員会の例であり、彼らは発電所自体のはるかに重要な設計よりも、自転車小屋の構造について議論することに時間の大半を費やしている。非常に大きく複雑なテーマについての議論では、高度な専門知識や準備がなければ、意味のあるな意見を述べることは難しいかもしれません。しかし、人々は意味のある意見を発言していると見られたいと思う傾向があり、そのため、簡単に推論できるが、必ずしも特別な重要性があるわけではないような些細なことに時間を集中させてしまう傾向がある。
+
+上記の架空の例では、些細な細部に時間を浪費するための表現として「自転車シェディング」という用語を使用しました。関連用語は「 [ヤクシェービング](https://ja.wiktionary.org/wiki/yak_shaving) 」です。これは、メインタスクの前提条件の長い連鎖の一部である、一見無関係な活動を意味します。
+
+### UNIX哲学
+
+[UNIX哲学-Wikipedia](https://ja.wikipedia.org/wiki/UNIX%E5%93%B2%E5%AD%A6)
+
+UNIX理念は、ソフトウェアの構成要素は小さく、一つの特定のことをうまく行うことに集中すべきであるというものです。これは、大規模で複雑な多目的プログラムを使うのではなく、小さくてシンプルで、よく定義されたユニットを組み合わせてシステムを構築することを容易にすることができます。
+
+現代における「マイクロサービス・アーキテクチャ」は、この法則の応用と考えることができ、サービスは小さく、焦点を絞って、特定の一つのことをしっかりと行うことで、複雑な動作をシンプルなビルディングブロックで構成することを可能にしています。
+
+### Spotifyモデル
+
+[Spotifyモデル-Spotify Labs(英語)](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/)
+
+Spotifyモデルとは、「Spotify」によって普及したチームと組織構造へのアプローチです。このモデルでは、チームはテクノロジーではなく機能を中心に組織されています。
+
+また、Spotify モデルでは、組織構造の他の要素である部族、ギルド、チャプターの概念も普及しています。
+
+### ワドラーの法則
+
+[ワドラーの法則-wiki.haskell.org(英語)](https://wiki.haskell.org/Wadler's_Law)
+
+> どのような言語設計においても、このリストの特徴を議論するのに費やされた時間の合計は、その位置の累乗に2を上げることに比例します。
+> 1. 意味論
+> 2. 構文
+> 3. 字句構文
+> 4. コメントの字句構文
+> （要するに、意味論に1時間使うとすると、8時間はコメントの構文に費やされます）。
+
+同様に[パーキンソンの凡俗法則](#パーキンソンの凡俗法則) 、和ドラーの法則は、言語を設計する際に、言語構造の重要性に比べて、言語構造に費やされる時間が不釣り合いに多いということが述べられています。
+
+関連項目:
+
+- [パーキンソンの凡俗法則](#パーキンソンの凡俗法則)
+
+### ウィートンの法則
+
+[リンク(英語)](http://www.wheatonslaw.com/)
+
+[公式日(英語)](https://dontbeadickday.com/)
+
+> 嫌な奴になるな
+> *ウィル・ウィートン*
+
+ウィル・ウィートン（スタートレック：ネクスト・ジェネレーション、ビッグバン・セオリー）によって考案されたこのシンプルで簡潔で強力な法則は、専門的な組織内での調和と尊敬を高めることを目的としています。同僚との会話、コードレビューの実行、他の視点からの反論、批評、そして一般的に、ほとんどのプロフェッショナルな人間関係に適用することができます。
+
+## 原則
+
+一般に、原則は設計に関するガイドラインである可能性が高くなります。
+
+### ディルバートの原理
+
+[ディルバートの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%A3%E3%83%AB%E3%83%90%E3%83%BC%E3%83%88%E3%81%AE%E6%B3%95%E5%89%87)
+
+> 企業は、事業への損害を最小限にとどめるために、系統立てて無能な者から管理職に昇進させて行く傾向がある
+> *スコットアダムス*
+
+スコット・アダムス（漫画「ディルバート」の作者）が開発した経営概念で、ディルバート原則は[、ピーター原則に](#ピーターの原則)触発されています。ディルバートの原則では、有能でない社員を管理職に昇格させることで、事業への損害を最小限にとどめる。 Adamsは、1995年のウォールストリートジャーナルの記事でこの原則を最初に説明し、1996年のビジネスブック、 [The Dilbert Principleで](#関連書籍)それを拡張しました。
+
+関連項目:
+
+- [ピーターの原則](#ピーターの原則)
+- [パットの法則](#パットの法則)
+
+### パレート原理（80/20ルール）
+
+[パレートの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%91%E3%83%AC%E3%83%BC%E3%83%88%E3%81%AE%E6%B3%95%E5%89%87)
+
+> 人生のほとんどのものが均等に分配されていません。
+
+パレートの原理は、いくつかのケースでは、結果の大部分は少数の入力から来ることを示唆している。
+
+- 特定のソフトウェアの80％は、割り当てられた合計時間の20％で実装できます（逆に、コードの最も難しい20％部分を実装するのに時80％の時間がかかります）
+- 2割の努力は8割の結果を生む
+- 2割の仕事が8割の収益を生み出す
+- 20%のバグが80%のクラッシュを引き起こす
+- 20%の機能が80%の使用率を引き起こす
+
+ 1940年代には、品質管理の父と広く信じられているアメリカ・ルーマニアのエンジニア、ジョセフ・ジュラン博士が[、パレートの原則を品質問題に適用し始めました](https://en.wikipedia.org/wiki/Joseph_M._Juran) 。
+
+この原則は、次のようにも知られています。80/20ルール、バイタル・フューの法則、ファクター・スパーシティの原理。
+
+実際の例：
+
+- 2002年に、Microsoftは、最も報告されたバグの上位20％を修正することにより、windowsやofficeの関連するエラーやクラッシュの80%が解消されると報告しています（ [参考文献](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm) ）。
+
+### ピーターの原則
+
+[ピーターの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%94%E3%83%BC%E3%82%BF%E3%83%BC%E3%81%AE%E6%B3%95%E5%89%87)
+
+> 階層社会では、人間は能力の極限まで出世する。
+> *ローレンス・J・ピーター*
+
+ローレンス・J・ピーターによって開発された経営概念で、ピーターの原則は、仕事が得意な人は、もはや成功しないレベル（彼らの「無能のレベル」）に達するまで、昇進すると観察しています。この時点では、彼らはより熟練であるため、組織から外される可能性は低く、彼らを成功に導いた元々のスキルが必ずしも新しい仕事に必要なスキルであるとは限らないため、彼らが本来持っているスキルがほとんどない役割に留まり続けることになります。
+
+これは、最初はエンジニアとしてキャリアをスタートさせ、他のエンジニアの*管理に*つながるキャリアパスを描いているエンジニアにとって、特に興味深いものです。管理職には、根本的にエンジニアとは異なるスキルセットが必要です。
+
+関連項目:
+
+- [ディルバートの原理](#ディルバートの原理)
+- [パットの法則](#パットの法則)
+
+### 堅牢性の原則（ポステルの法則）
+
+[堅牢性の原則-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Robustness_principle)
+
+> 自分のやることは慎重に、他人から受け入れるときは自由に。
+
+サーバーアプリケーションの開発によく適用されるこの原則は、他のシステムに送るものは可能な限り最小限にして、適合性のあるものにすべきであるが、処理できる場合には、適合性のない入力を許容することを目指すべきである、ということを述べています。
+
+この原則の目標は、ハンドルできる場合には、不適合な入力を処理できるので、堅牢なシステムを構築することです。しかし、特にそのような入力の処理が十分にテストされていない場合には、不適合な入力を受け入れることにはセキュリティ上の問題がある可能性があります。
+
+不適合な入力を許可すると、実装者が最終的にこの自由に依存して機能を構築するようになるため、プロトコルが進化する可能性が損なわれる場合があります。
+
+関連項目:
+
+- [ハイラムの法則](#ハイラムの法則暗黙のインターフェースの法則)
+
+### SOLID
+
+これは以下を指す頭字語です。
+
+- S： [単一責任の原則](#単一責任の原則)
+- O： [開放/閉鎖原則](#開放閉鎖原則)
+- L： [リスコフ代替原則](#リスコフの置換原則)
+- I： [インターフェース分離の原則](#インターフェース分離の原則)
+- D： [依存関係の逆転の原則](#依存性逆転の原則)
+
+これらは、 [オブジェクト指向プログラミングの](#todo)主要な原則です。このような設計原則は、開発者が保守しやすいシステムを構築するのに役立つはずです。
+
+### 単一責任の原則
+
+[単一責任原則-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Single_responsibility_principle)
+
+> すべてのモジュールやクラスは、単一の責任のみを持つべきです。
+
+「 [SOLID](#solid) 」第一原則。この原則は、モジュールやクラスは一つのことを一つのことだけを行うべきだということを提案しています。より実用的な用語では、これはプログラムの機能への単一の小さな変更は、1つのコンポーネントのみの変更を必要とすることを意味します。例えば、パスワードの複雑さを検証する方法を変更するには、プログラムの一部分だけを変更する必要があります。
+
+理論的には、これによりコードがより堅牢になり、変更が容易になるはずです。変更されるコンポーネントが単一の責任を持っていることを知ることは、その変更の*テスト*がより簡単になることを意味します。先ほどの例を使うと、パスワードの複雑さのコンポーネントを変更することは、パスワードの複雑さに関連する機能にのみ影響を与えることができるはずです。多くの責任を持つコンポーネントへの変更の影響を推論することは、はるかに難しいでしょう。
+
+関連項目:
+
+- [オブジェクト指向プログラミング](#todo)
+- [SOLID](#solid)
+
+### 開放/閉鎖原則
+
+[開放/閉鎖原則-Wikipedia](https://ja.wikipedia.org/wiki/%E9%96%8B%E6%94%BE/%E9%96%89%E9%8E%96%E5%8E%9F%E5%89%87)
+
+> エンティティは拡張のために開かれ、修正のために閉じられるべきです。
+
+「 [SOLID](#solid) 」第二原則。この原則では、エンティティー（クラス、モジュール、関数など）は動作を*拡張*することができなければならないが、 *既存*の振る舞いは修正することができないべきではないということを述べています。
+
+仮定としてMarkdown文書をHTMLに変換することができるモジュールを想像してください。モジュールがモジュール内部を修正することなく、新しく提案されたMarkdown機能を処理するために拡張できた場合、拡張のためにオープンになります。既存のMarkdown機能が処理されるように、モジュールが利用者によって*修正されない*場合、修正のために*クローズド*になります。
+
+この原則は、オブジェクト指向プログラミングに特に関連しています。簡単に拡張するオブジェクトを設計するかもしれませんが、予期しない方法で変更された既存の動作を持つことができるオブジェクトを設計することを避けます。
+
+関連項目:
+
+- [オブジェクト指向プログラミング](#todo)
+- [SOLID](#solid)
+
+### リスコフの置換原則
+
+[リスコフの置換原則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%AA%E3%82%B9%E3%82%B3%E3%83%95%E3%81%AE%E7%BD%AE%E6%8F%9B%E5%8E%9F%E5%89%87)
+
+> システムを壊すことなく、タイプをサブタイプに置き換えることができるはずです。
+
+「 [SOLID](#solid) 」原則の3番目。この原則は、コンポーネントがタイプに依存している場合、システムに障害が発生したり、そのサブタイプが何であるかの詳細を知る必要なく、そのタイプのサブタイプを使用できるはずであると述べています。
+
+例として、ファイルを表す構造からXMLドキュメントを読み取るメソッドがあるとします。メソッドが基本タイプ「ファイル」を使用する場合、「ファイル」から派生するものはすべて関数で使用できるはずです。 「ファイル」が逆方向のシークをサポートし、XMLパーサーがその関数を使用するが、逆型シークが試行されたときに派生型「ネットワークファイル」が失敗する場合、「ネットワークファイル」は原則に違反しています。
+
+この原則は、オブジェクト指向プログラミングに特に関連しています。システムのユーザーを混乱させないように、型階層を注意深くモデル化する必要があります。
+
+関連項目:
+
+- [オブジェクト指向プログラミング](#todo)
+- [SOLID](#solid)
+
+### インターフェース分離の原則
+
+[インターフェース分離原則-Wikipedia(英語版)](https://en.wikipedia.org/wiki/Interface_segregation_principle)
+
+> 使用しないメソッドに依存することを強制されるクライアントはありません。
+
+「 [SOLID](#solid) 」原則の4番目。この原則は、コンポーネントのコンシューマーが、実際に使用しないコンポーネントの機能に依存すべきではないと述べています。
+
+例として、ファイルを表す構造体からXML文書を読み込むメソッドがあるとします。このメソッドが必要とするのは、ファイル内のバイトを読み込んだり、前に移動したり、後ろに移動したりすることだけです。ファイル構造体の無関係な機能が変更されたためにこのメソッドを更新する必要がある場合（ファイルのセキュリティを表現するために使用されるパーミッションモデルの更新など）、その原則は無効になっています。ファイルは「シーク可能なストリーム」インターフェースを実装し、XMLリーダーはそれを使用する方が良いでしょう
+
+この原則はオブジェクト指向プログラミングに特に関連性があり、インターフェイス、階層構造、抽象型が異なるコンポーネント間の結合を[最小限](#todo)にするために使用されます。[ダックタイピング](#todo)は、明示的なインターフェースを排除することでこの原則を強制する方法論です。
+
+関連項目:
+
+- [オブジェクト指向プログラミング](#todo)
+- [SOLID](#solid)
+- [ダックタイピング](#todo)
+- [デカップリング](#todo)
+
+### 依存性逆転の原則
+
+[依存性逆転の原則-Wikipedia](https://ja.wikipedia.org/wiki/%E4%BE%9D%E5%AD%98%E6%80%A7%E9%80%86%E8%BB%A2%E3%81%AE%E5%8E%9F%E5%89%87)
+
+> 高レベルのモジュールは、低レベルの実装に依存すべきではありません。
+
+「 [SOLID](#solid) 」原則の5番目。この原則は、より高いレベルのオーケストレーションコンポーネントは、依存関係の詳細を知っている必要はないことを述べています。
+
+例として、ウェブサイトからメタデータを読み取るプログラムがあるとします。メインコンポーネントは、ウェブページのコンテンツをダウンロードするためのコンポーネントについて知る必要があり、メタデータを読み取ることができるコンポーネントであると想定します。依存関係の逆転を考慮すると、メインコンポーネントは、バイトデータをフェッチできる抽象コンポーネントと、バイトストリームからメタデータを読み取ることができる抽象コンポーネントのみに依存します。メインコンポーネントは、TCP / IP、HTTP、HTMLなどについては認識しません。
+
+この原則は複雑です。システムの予想される依存関係（したがって、名前）を「逆転」するように見える場合があるためです。実際には、別のオーケストレーションコンポーネントが抽象型の正しい実装が使用されていることを確認する必要があることも意味します（たとえば、前の例では、 *何か*がメタデータリーダーコンポーネントにHTTPファイルダウンローダーとHTMLメタタグリーダーを提供する必要があります）。次に、 [Inversion of Control](#todo)や[Dependency Injection](#todo)などのパターンに触れます。
+
+関連項目:
+
+- [オブジェクト指向プログラミング](#todo)
+- [SOLID](#solid)
+- [制御の反転](#todo)
+- [依存性注入](#todo)
+
+### DRY原則
+
+[Don't repeat yourself-Wikipedia](https://ja.wikipedia.org/wiki/Don%27t_repeat_yourself)
+
+> すべての知識は、システム内で単一の明確で信頼できる表現を持つ必要があります。
+
+DRYは、 *Do n't Repeat Yourselfの*頭字語です。この原則は、開発者がコードの繰り返しを減らして情報を1か所に保管できるようにすることを目的としており、1999年にAndrew HuntとDave Thomasが 『 [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) 』で引用しています。
+
+> DRYの反対は*WET* （すべてを2回書き込むか、タイピングを楽しむ）です。
+
+実際には、2つ（またはそれ以上）の異なる場所に同じ情報がある場合、DRYを使用してそれらを1つの場所にマージし、必要な場所で必要に応じて再利用できます。
+
+関連項目
+
+- [実用的な開発者(英語)](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+
+### KISSの原則
+
+[KISSの原則-Wikipedia](https://ja.wikipedia.org/wiki/KISS%E3%81%AE%E5%8E%9F%E5%89%87)
+
+> 簡潔に単純にしておけ
+
+KISSの原則は、ほとんどのシステムは複雑にするのではなく、シンプルに保つことが最もよく機能するというもので、シンプルさは設計の重要な目標であり、不必要な複雑さは避けるべきだというものです。 1960年にアメリカ海軍で始まったこのフレーズは、航空機エンジニアのケリー・ジョンソンに関連しています。
+
+この原則は、ジョンソンが設計エンジニアのチームに一握りの工具を渡し、設計しているジェット機は、現場の平均的な整備士がこれらの工具だけで戦闘状況下で修理可能なものでなければならないという課題を与えたという話に最もよく例示されています。したがって、「バカ」とは、技術者自身の能力ではなく、物の壊れ方と、それを修理するために利用できる道具の巧妙さの関係を指しています。
+
+関連項目:
+
+- [ゴールの法則](#ゴールの法則)
+
+### YAGNI
+
+[YAGNI-Wikipedia](https://ja.wikipedia.org/wiki/YAGNI)
+
+ ***Y**ou **A**in't **G**onna **N**eed **I**t*"縮めて YAGNI
+
+> 実際にそれらが必要なときに常に実装し、必要があると予測しただけでは決して実装しないでください。
+> （ [Ron Jeffries](https://twitter.com/RonJeffries) ）（XPの共同創設者であり、「Extreme Programming Installed」という本の著者）
+
+この*エクストリームプログラミング* （XP）の原則は、開発者は当面の要件に必要な機能のみを実装し、後で必要になる可能性のある機能を実装して将来を予測しようとする試みを避けることを示唆しています。
+
+この原則を順守することで、コードベース内の未使用のコードの量を減らし、価値のない機能に時間と労力が浪費されるのを防ぐことができます。
+
+関連項目
+
+- [関連書籍：インストールされているExtremeプログラミング](#関連書籍)
+
+### 分散コンピューティングの落とし穴
+
+[分散コンピューティングの落とし穴-Wikipedia](https://ja.wikipedia.org/wiki/%E5%88%86%E6%95%A3%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E3%81%AE%E8%90%BD%E3%81%A8%E3%81%97%E7%A9%B4)
+
+「*ネットワークコンピューティングの落とし穴*」としても知られているこの落とし穴は、ソフトウェア開発の失敗につながる可能性のある、分散コンピューティングに関する思い込み(または信念)のリストです。仮定は以下の通りです。
+
+- ネットワークは信頼できる
+- 待ち時間はゼロです
+- 帯域幅は無限です
+- ネットワークは安全です
+- トポロジーは変わらない
+- 管理者が一人だけいます
+- トランスポートコストはゼロ
+- ネットワークは均一です
+
+最初の4つの項目は、1991年頃に[Bill Joy](https://en.wikipedia.org/wiki/Bill_Joy)と[Tom Lyon](https://twitter.com/aka_pugs)によってリストされ、 [James Gosling](https://en.wikipedia.org/wiki/James_Gosling)によって最初に「ネットワークコンピューティングの失墜」として分類されました。 [L.ピータードイチュ](https://en.wikipedia.org/wiki/L._Peter_Deutsch)は、5、6、7番目の誤りを追加しました。 90年代後半、ゴスリングは8番目の誤りを追加しました。
+
+このグループは、 [Sun Microsystemsの](https://en.wikipedia.org/wiki/Sun_Microsystems)内部で当時何が起こっていたかに触発されました。
+
+これらの誤りは、弾力性のあるコードを設計するときに注意深く検討する必要があります。これらの誤りのいずれかが、分散システムの現実と複雑さに対処できない欠陥のあるロジックにつながる可能性があると仮定します。
+
+関連項目:
+
+- [分散コンピューティングの落とし穴の採餌（パート1）-Vaidehi Joshi
+    中(英語)](https://medium.com/baseds/foraging-for-the-fallacies-of-distributed-computing-part-1-1b35c3b85b53)
+- [Deutsch's Fallacies、10年後(英語)](http://java.sys-con.com/node/38665)
+
+## 関連書籍:
+
+もっと興味を感じたなら、以下の本を参照してください。
+
+- [インストールされているエクストリームプログラミング-ロンジェフリーズ、アンアンダーソン、チェットヘンドリクソン](https://www.goodreads.com/en/book/show/67834) -エクストリームプログラミングのコア原則をカバーしています。
+- [The Mythical Man Month-フレデリックP.ブルックスJr.-](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month)ソフトウェアエンジニアリングに関する古典的な巻。 [ブルックスの法則](#ブルックスの法則)は本の中心的なテーマです。
+- [ゲーデル、エッシャー、バッハ：永遠のゴールデンブレイド-ダグラスR.ホフスタッター。](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) -この本は分類するのが難しいです。 [ホフスタッターの法則](#ホフスタッターの法則)は本からです。
+- [ディルバートの原則-スコットアダムス](https://www.goodreads.com/book/show/85574.The_Dilbert_Principle) - [ディルバートの原則](#ディルバートの原理)を作成した作者によるアメリカの企業の漫画の外観。
+- [ピーター原則-ローレンスJ.ピーター](https://www.goodreads.com/book/show/890728.The_Peter_Principle) - [ピーター原則の](#ピーターの原則)出典である、より大きな組織と人々の管理の課題に関する別の漫画の見方。
+
+## 翻訳
+
+多くの素晴らしい投稿者のおかげで、ハッカーの法則は多くの言語で利用可能です。モデレーターのスポンサーもご検討ください。
+
+言語 | モデレータ | ステータス
+--- | --- | ---
+[🇧🇷 Brasileiro / Brazilian](../translations/pt-BR.md) | [Eugênio Moreira](https://github.com/eugenioamn), [Leonardo Costa](https://github.com/leofc97) | [![gitlocalized ](https://gitlocalize.com/repo/2513/pt-BR/badge.svg)](https://gitlocalize.com/repo/2513/pt-BR?utm_source=badge)[](https://gitlocalize.com/repo/2513/pt-BR?utm_source=badge)[](https://gitlocalize.com/repo/2513/pt-BR?utm_source=badge)
+[🇨🇳 中文 / Chinese](https://github.com/nusr/hacker-laws-zh) | [Steve Xu](https://github.com/nusr) | Partially complete
+[🇩🇪 Deutsch / German](../translations/de.md) | [Vikto](https://github.com/viktodergunov) | [![gitlocalized ](https://gitlocalize.com/repo/2513/de/badge.svg)](https://gitlocalize.com/repo/2513/de?utm_source=badge)[](https://gitlocalize.com/repo/2513/de?utm_source=badge)[](https://gitlocalize.com/repo/2513/de?utm_source=badge)
+[🇫🇷 Français / French](../translations/fr.md) | [Kevin Bockelandt](https://github.com/KevinBockelandt) | [![gitlocalized ](https://gitlocalize.com/repo/2513/fr/badge.svg)](https://gitlocalize.com/repo/2513/fr?utm_source=badge)[](https://gitlocalize.com/repo/2513/fr?utm_source=badge)[](https://gitlocalize.com/repo/2513/fr?utm_source=badge)
+[🇬🇷 ελληνικά / Greek](../translations/el.md) | [Panagiotis Gourgaris](https://github.com/0gap) | [![gitlocalized ](https://gitlocalize.com/repo/2513/el/badge.svg)](https://gitlocalize.com/repo/2513/el?utm_source=badge)[](https://gitlocalize.com/repo/2513/el?utm_source=badge)[](https://gitlocalize.com/repo/2513/el?utm_source=badge)
+[🇮🇹 Italiano / Italian](https://github.com/csparpa/hacker-laws-it) | [Claudio Sparpaglione](https://github.com/csparpa) | Partially complete
+[🇰🇷 한국어 / Korean](https://github.com/codeanddonuts/hacker-laws-kr) | [Doughnut](https://github.com/codeanddonuts) | Partially complete
+[🇱🇻 Latviešu Valoda / Latvian](../translations/lv.md) | [Arturs Jansons](https://github.com/iegik) | [![gitlocalized ](https://gitlocalize.com/repo/2513/lv/badge.svg)](https://gitlocalize.com/repo/2513/lv?utm_source=badge)[](https://gitlocalize.com/repo/2513/lv?utm_source=badge)[](https://gitlocalize.com/repo/2513/lv?utm_source=badge)
+[🇷🇺 Русская версия / Russian](https://github.com/solarrust/hacker-laws) | [Alena Batitskaya](https://github.com/solarrust) | Partially complete
+[🇪🇸 Castellano / Spanish](../translations/es-ES.md) | [Manuel Rubio](https://github.com/manuel-rubio) ([Sponsor](https://github.com/sponsors/manuel-rubio)) | Partially complete
+[🇹🇷 Türkçe / Turkish](https://github.com/umutphp/hacker-laws-tr) | [Umut Işık](https://github.com/umutphp) | [![gitlocalized ](https://gitlocalize.com/repo/2513/tr/badge.svg)](https://gitlocalize.com/repo/2513/tr?utm_source=badge)[](https://gitlocalize.com/repo/2513/tr?utm_source=badge)[](https://gitlocalize.com/repo/2513/tr?utm_source=badge)
+| [JP 日本語 / Japanese](../translations/jp.md) | [Fumikazu Fujiwara](https://github.com/freddiefujiwara)|Partially complete  |
+
+翻訳を更新したい場合は、 [open a pull request](https://github.com/dwmkerr/hacker-laws/pulls)するだけです。新しい言語を追加したい場合は、 [GitLocalize](https://gitlocalize.com/) にログインしてアカウントを作成し、言語の管理を依頼するためのissueを開いてください。また、上の表とファイルの先頭にあるリンクを更新するプルリクエストを開いていただけると、とても助かります。
+
+## 関連プロジェクト
+
+- [今日のヒント(英語)](https://tips.darekkay.com/html/hacker-laws-en.html) -毎日ハッカーの法則/原則の更新を知ることができます。
+- [ハッカーの法則コマンド](https://github.com/umutphp/hacker-laws-cli)あなたの端末上でランダムな法則を一覧表示、表示、確認できます。
+
+## 貢献方法
+
+貢献してください! 追加や変更を提案したい場合は  [Raise an issue](https://github.com/dwmkerr/hacker-laws/issues/new)、変更を提案したい場合は  [Open a pull request](https://github.com/dwmkerr/hacker-laws/compare) をご利用ください。
+
+文章やスタイルなどの要件については、[Contributing Guidelines](./.github/contributing.md)  を必ずお読みください。プロジェクトの議論に参加する際には、[Code of Conduct](./.github/CODE_OF_CONDUCT.md)を意識してください。
+
+## TODO
+
+こんにちは！あなたがここに来たということは、私がまだ書き上げていないトピックへのリンクをクリックしたことにですね。
+
+リクエストしたい場合は  [Raise an Issue](https://github.com/dwmkerr/hacker-laws/issues) をクリックするか、トピックの定義案を提出したい場合は [Open a Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) をクリックしてください。

translations/lv.md

@@ -0,0 +1,783 @@
+# 💻 📖 hacker-laws
+
+[![gitlocalized](https://gitlocalize.com/repo/2513/whole_project/badge.svg)](https://gitlocalize.com/repo/2513/whole_project?utm_source=badge)
+
+Likumi, teorijas, principi un apraksti, kas izstrādātājiem šķitīs noderīgi.
+
+- 🇨🇳 [中文/Chinese Version](https://github.com/nusr/hacker-laws-zh) - paldies [Steve Xu](https://github.com/nusr)!
+- 🇮🇹 [traduzione Italiano](https://github.com/dwmkerr/hacker-laws/blob/master/translations/it-IT.md) - paldies [Claudio Sparpaglione](https://github.com/csparpa)!
+- 🇰🇷 [한국어/korejiešu versija](https://github.com/codeanddonuts/hacker-law-kr) - paldies [Doughnut](https://github.com/codeanddonuts)!
+- 🇷🇺 [Русская версия/Krievijas versija](https://github.com/solarrust/hacker-laws) - paldies [Alena Batitskaya](https://github.com/solarrust)!
+- 🇹🇷 [türkçe/Turkish Version](https://github.com/umutphp/hacker-laws-tr) - paldies [Umut Işık](https://github.com/umutphp)
+- 🇧🇷 [Brasileiro/Brazīlijas versija](./translations/pt-BR.md) - paldies [Leonardo Costa](https://github.com/LeoFC97)
+- 🇪🇸 [Castellano/Spānijas versija](./translations/es-ES.md) - paldies [Manuel Rubio](https://github.com/manuel-rubio)
+- 🇱🇻 [Latvian/Latvijas versija](./translations/lv.md) - paldies [Artūrs Jansons](https://github.com/iegik)
+- 🇺🇸 [Original English Version - Oriģinālā angļu versija](https://github.com/dwmkerr/hacker-laws) - paldies [Dave Kerr](https://github.com/dwmkerr)!
+
+Kā šis projekts? Lūdzu, apsveriet iespēju [Sponsoring Me](https://github.com/sponsors/dwmkerr)!
+
+---
+
+<!-- VIM-markdown-toc GFM -->
+
+* [Ievads](#ievads)
+* [Likumi](#likumi)
+    * [Amdahla likums](#amdahla-likums)
+    * [Izsisto logu teorija](#izsisto-logu-teorija)
+    * [Brūku likums](#bruku-likums)
+    * [Konveja likums](#conways-likums)
+    * [Kaningemas likums](#cunninghams-likums)
+    * [Danbara numurs](#dunbars-numurs)
+    * [Galla likums](#galls-likums)
+    * [Goodharta likums](#goodharts-likums)
+    * [Hanona Razora](#hanlons-razor)
+    * [Hofstadtera likums](#hofstadtera-likums)
+    * [Hutbera likums](#hutbera-likums)
+    * [Hype Cycle & Amaras likums](#hype-cycle-amaras-likums)
+    * [Hyruma likums (Perifērisko saskarņu likums)](#hyruma-likums-perifērisko-saskarņu-likums)
+    * [Kernigana likums](#kernigana-likums)
+    * [Metkalfa likums](#metkalfa-likums)
+    * [Mora likums](#mora-likums)
+    * [Mērfija likums/Soda likums](#murphys-sods-likums)
+    * [Occam's Razor](#occams-razor)
+    * [Parkinsona likums](#parkinsons-Law)
+    * [Priekšlaicīgas optimizēšanas efekts](#premature-optimizēšanas-efekts)
+    * [Putta likums](#putta-likums)
+    * [Reeda likums](#reeda-likums)
+    * [Taisnīguma saglabāšanas likums (Teslera likums)](#taisnīguma-saglabāšanas-likums-teslera-likums)
+    * [Leaky Abstractions likums](#leaky-Abstractions-likums)
+    * [Trivialitātes likums](#trivialitātes-likums)
+    * [Unix filozofija](#unix-filozofija)
+    * [Spotify modelis](#spotify-modelis)
+    * [Wadlera likums](#wadlera-likums)
+    * [Wheatona likums](#wheatons-likums)
+* [Principi](#principi)
+    * [Dilberta princips](#dilberta-princips)
+    * [Pareto princips (kārtula 80/20)](#pareto-princips-kārtula-8020)
+    * [Petera princips](#petera-princips)
+    * [Uzturības princips (Postela likums)](#uzturības-princips-postela-likums)
+    * [SOLID](#solid)
+    * [Vienotās atbildības princips](#vienotās-atbildības-princips)
+    * [Atklātais/slēgtais princips](#atklātaisslēgtais-princips)
+    * [Liskova aizstāšanas princips](#liskova-aizstāšanas-princips)
+    * [Interfeisa segmenta noteikšanas princips](#interfeisa-segmenta-noteikšanas-princips)
+    * [Atkarībās inversijas princips](#atkarības-inversijas-princips)
+    * [DRY princips](#dry-princips)
+    * [KISS princips](#kiss-princips)
+    * [YAGNI](#yagni)
+    * [Dalītās datošanas maldības](#dalītās-datošanas-maldības)
+* [Lasīšanas saraksts](#lasīšanas-saraksts)
+* [Ieguldījums](#ieguldījums)
+* [Uzdevums](#TODO)
+
+<!-- VIM-markdown-toc -->
+
+## Ievads
+
+Ir daudz likumu, kurus cilvēki apspriež, runājot par attīstību. Šis repozitorijs ir atsauce un pārskats par dažiem visbiežāk sastopamajiem. Lūdzu, kopīgojiet un iesniedziet PRs!
+
+❗: šis repo satur dažu likumu, principu un modeļu skaidrojumu, bet ne _aizstāv_ nevienam no tiem. Tas, vai tās jāpiemēro, vienmēr būs debašu jautājums un lielā mērā atkarīgs no tā, ar ko jūs strādājat.
+
+## Tiesību akti
+
+Un te nu mēs ejam!
+
+### Amdahl likums
+
+[Amdahl likums Vikipēdijā](https://en.wikipedia.org/wiki/Amdahl%27s_law)
+
+> Amdahl likums ir formula, kas parāda skaitļošanas uzdevuma _increedup_, ko var sasniegt, palielinot sistēmas resursus. Parasti izmanto paralēlā skaitļošanā, tā var paredzēt faktisko labumu no procesoru skaita palielināšanas, ko ierobežo programmas paralēliskās iespējas.
+
+Vislabāk ilustrēts ar piemēru. Ja programma sastāv no divām daļām, daļas A, kas jāizpilda vienam procesoram, un daļas B, ko var līdzināt, mēs redzam, ka vairāku procesoru pievienošana sistēmai, kas izpilda programmu, var sniegt tikai ierobežotu labumu. Tas var ievērojami uzlabot B daļas ātrumu, bet daļas a ĀTRUMS paliks nemainīgs.
+
+Turpmāk redzamajā diagrammā ir parādīti daži iespējamo ātruma uzlabojumu piemēri.
+
+<img alt="Diagram: Amdahla likums" src="../images/amdahls_law.png" width="480px"/>
+
+*(Atsauce uz attēlu: Daniels220 angļu valodā Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)*
+
+Kā redzams, pat programma, kas ir 50% parallelisable, gūs ļoti maz vairāk nekā 10 procesoru vienību, bet programma, kas ir 95% parallelisable, joprojām var sasniegt ievērojamus ātruma uzlabojumus ar vairāk nekā tūkstoš procesoriem.
+
+Tā kā [Mora likums](#mora-likums) palēninās un individuālā procesora ātruma paātrināšanās palēninās, paralelizācija ir būtiska, lai uzlabotu veiktspēju. Grafikas programmēšana ir lielisks piemērs - ar mūsdienu Shader bāzes skaitļošanu, atsevišķiem pikseļiem vai fragmentiem var renderēt paralēli - tāpēc mūsdienu grafikas kartēs bieži vien ir daudz tūkstošu apstrādes kodolu (GPUs vai Shader Units).
+
+Skatīt arī:
+
+- [Brūku likums](#brooks-likums)
+- [Mora likums](#mora-likums)
+
+### Izsisto logu teorija
+
+[Izsisto logu teorija Vikipēdijā](https://en.wikipedia.org/wiki/Broken_windows_theory)
+
+Izsisto logu teorija liecina, ka redzamas nozieguma pazīmes (vai kādas vides rūpju trūkums) noved pie tālākiem un smagākiem noziegumiem (vai tālākas vides pasliktināšanās).
+
+Šī teorija ir izmantota programmatūras izstrādei, kas liek domāt, ka sliktas kvalitātes kods (vai [Technical Debt](#TODO)) var radīt priekšstatu, ka kvalitātes uzlabošanas centieni var tikt ignorēti vai nepietiekami novērtēti, tādējādi radot vēl vairāk sliktas kvalitātes kodu. Šī efekta kaskādes izraisa ievērojamu kvalitātes samazināšanos laika gaitā.
+
+Skatīt arī:
+
+- [Tehniskais parāds](#TODO)
+
+Piemēri:
+- [Pracistic Programming: Software Entropy](https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy)
+- [Coding Horror: The Broken Window Theory](https://blog.codinghorror.com/the-break-window-theory/)
+- [OpenSource: Joy of Programming - The Broken Window Theory](https://opensourceforu.com/2011/05/joy-of-programming-broken-window-theory/)
+
+### Brūku likums
+
+[Brūku likums Vikipēdijā](https://en.wikipedia.org/wiki/Brooks%27s_law)
+
+> Personāla resursu pievienošana vēlākam programmatūras izstrādes projektam to dara vēlāk.
+
+Šis likums liek domāt, ka daudzos gadījumos mēģinājums paātrināt tāda projekta īstenošanu, kas jau ir novēlots, pieskaitot vairāk cilvēku, padarīs piegādi vēl vēlāku. Bruks ir skaidrs, ka tā ir pārmērīga vienkāršošana, tomēr vispārīgie apsvērumi ir tādi, ka, ņemot vērā jaunu resursu ieviešanas laiku un sakaru pieskaitāmās izmaksas, tuvākajā laikā ātrums samazinās. Turklāt daudzi uzdevumi var nebūt dalāmi, t. i., viegli sadalāmi starp lielākiem resursiem, kas nozīmē, ka arī potenciālais ātruma pieaugums ir mazāks.
+
+Izplatītā frāze “Deviņi sievietes nevar dzemdēt bērnu vienā mēnesī” attiecas uz Brūku likumu, jo īpaši uz faktu, ka daži darba veidi nav dalāmi vai parallelisable.
+
+Šī ir grāmatas “[The Mythical Man Monthly](#lasīšanas-saraksts)” galvenā tēma.
+
+Skatīt arī:
+
+- [Nāves marts](#TODO)
+- [reading List: The Mythical Man Month](#reading saraksts)
+
+### Konveja likums
+
+[Conwaya likums Vikipēdijā](https://en.wikipedia.org/wiki/Conway%27s_law)
+
+Šis likums paredz, ka sistēmas tehniskās robežas atspoguļos organizācijas struktūru. Parasti tas tiek pieminēts, aplūkojot organizācijas uzlabojumus, Konveja likums liecina, ka, ja organizācija ir strukturēta uz daudzām mazām, atvienotām vienībām, tad tā ražotā programmatūra būs. Ja organizācija ir vairāk izveidota, izmantojot "vertikāles”, kas ir orientētas uz līdzekļiem vai pakalpojumiem, arī programmatūras sistēmas to atspoguļo.
+
+Skatīt arī:
+
+- [Spotify modelis](#spotify-modelis)
+
+### Kaningemas likums
+
+[Kaningemas likums Vikipēdijā](https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham_likums)
+
+> Labākais veids, kā iegūt pareizo atbildi internetā, ir neuzdot jautājumu, tas ir, izlikt nepareizu atbildi.
+
+Pēc Stīvena McGeady teiktā, Vords Kaningems astoņdesmito gadu sākumā viņam ieteicis: “Labākais veids, kā iegūt pareizo atbildi internetā, ir neuzdot jautājumu, tas ir, izlikt nepareizu atbildi.” Mcgeady šo Kaningemas likumu nodēvēja par “nepatiesu”, lai gan Kaningems to noliedz. Lai gan sākotnēji tas attiecās uz mijiedarbību ar Usenet, likums ir izmantots, lai aprakstītu, kā darbojas citas tiešsaistes kopienas (piemēram, Wikipedia, Reddit, Twitter, Facebook).
+
+Skatīt arī:
+
+- [XKCD 386: “Duty Calls”](https://xkcd.com/386/)
+
+### Danbara numurs
+
+[Danbara numurs Vikipēdijā](https://en.wikipedia.org/wiki/Dunbar%27s_number)
+
+“Danbara skaitlis ir ieteicams izziņas ierobežojums to cilvēku skaitam, ar kuriem var uzturēt stabilas sociālās attiecības — attiecības, kurās indivīds zina, kas ir katrs cilvēks un kā katrs cilvēks ir saistīts ar katru citu cilvēku.” Ir kādas domstarpības ar precīzu skaitli. “..” “Dunbar” ierosināja, ka cilvēki var mierīgi uzturēt tikai 150 stabilas attiecības.” Viņš ievietoja numuru vairāk sabiedriskā kontekstā, “tik daudz cilvēku, cik jūs nejustos apmulsuši, ka pievienojaties nelūgtam dzērienam, ja jums gadītos ar viņiem ieskrieties bārā.” Aptuvenie skaitļi parasti ir no 100 līdz 250.
+
+Tāpat kā stabilas attiecības starp indivīdiem, arī izstrādātāja attiecības ar kodebīlu prasa pūles uzturēt. Saskaroties ar lieliem sarežģītiem projektiem vai daudzu projektu īpašumtiesībām, mēs paļaujamies uz konvencionālo, politiku un modelēto procedūru mērogu. Danbara numurs ir svarīgs ne tikai biroja izaugsmei, bet arī, nosakot darba grupas darba apjomu vai lemjot par to, kad sistēmai jāiegulda līdzekļi, lai palīdzētu modelēt un automatizēt loģistikas pieskaitāmās izmaksas. Skaitlis tiek iekļauts tehniskā kontekstā, tas ir tādu projektu skaits (vai atsevišķa projekta normalizēta sarežģītība), kuriem jūs justos droši, pievienojoties zvanu rotācijai, lai atbalstītu.
+
+Skatīt arī:
+
+- [Conwaya likums](#conways-likums)
+
+### Galla likums
+
+[Galla likums Vikipēdijā](https://en.wikipedia.org/wiki/John_Gall_(autors)#Gall's_law)
+
+> Salikta sistēmā, kas darbojas, pastāvīgi tiek atrasta, ka tā ir attīstījusies no vienkāršas sistēmas, kas darbojās. Sarežģīta sistēma, kas veidota no nulles, nekad nedarbojas, un to nevar patukšot, lai tā darbotos. Jāsāk ar vienkāršu darba sistēmu.
+>
+> ([John Gall](https://en.wikipedia.org/wiki/John_Gall_(autors)))
+
+Gall likums nozīmē, ka mēģinājumi _izstrādāt_ ļoti sarežģītas sistēmas var neizdoties. Ļoti sarežģītas sistēmas reti tiek veidotas vienā paņēmienā, bet attīstās no vienkāršākām sistēmām.
+
+Klasiskais piemērs ir vispasaules tīmeklis. Pašreizējā stāvoklī tā ir ļoti sarežģīta sistēma. Tomēr sākotnēji tas tika definēts kā vienkāršs veids satura koplietošanai starp akadēmiskajām institūcijām. Tas bija ļoti veiksmīgs šo mērķu sasniegšanā un attīstījās, lai laika gaitā kļūtu sarežģītāks.
+
+Skatīt arī:
+
+- [KISS (keep It Simple, Stupid)](#kiss-princips)
+
+### Goodharta likums
+
+[Goodharta likums Vikipēdijā](https://en.wikipedia.org/wiki/Goodhart's_law)
+
+> jebkura novērotā statistiskā regularitāte var sabrukt, kad uz to tiek izdarīts spiediens kontroles nolūkā.
+>
+> _Charles Goodhart_
+
+Bieži minēts arī kā:
+
+> kad pasākums kļūst par mērķi, tas vairs nav labs pasākums.
+>
+> _Merilinas Strathern_
+
+Likums nosaka, ka pasākuma virzītā optimizācija var izraisīt paša mērījumu rezultāta devalvāciju. Pārāk selektīvs pasākumu kopums ([KPI](https://en.wikipedia.org/wiki/Performance_indicator)), ko akli piemēro procesam, rada izkropļotu ietekmi. Cilvēki mēdz optimizēt vietējā līmenī, “spēlējot” sistēmu, lai tā atbilstu īpašiem rādītājiem, nevis pievērstu uzmanību viņu darbību visaptverošajiem rezultātiem.
+
+Reālpasaules piemēri:
+
+- izmēģinājumi bez pārbaudes atbilst koda pārklājuma prognozēm, neskatoties uz to, ka metrikas nolūks bija izveidot labi pārbaudītu programmatūru.
+- izstrādātāja snieguma rezultāts, ko norāda veikto rindu skaits, noved pie nepamatoti uzpūstas kodebāzes.
+
+Skatīt arī:
+
+- [Goodharta likums: How Measuring The Wrong Things Drive Immoral Bemoral haviour](https://coffeeandjunk.com/goodharts-campbells-law/)
+- [Dilbert on bug-free software](https://dilbert.com/strip/1995-11-13)
+
+### Hanlons Razors
+
+[Hanlon's Razor Vikipēdijā](https://en.wikipedia.org/wiki/Hanlon%27s_razor)
+
+> nekad nepiedēvē ļaunprātību, kas ir pietiekami izskaidrota ar muļķību.
+>
+> Roberts J. Hanlons
+
+Šis princips liek domāt, ka darbības, kas rada negatīvu rezultātu, nav sliktas gribas rezultāts. Tā vietā negatīvais iznākums drīzāk tiek attiecināts uz šīm darbībām un/vai ietekme netiek pilnībā izprasta.
+
+### Hofstadtera likums
+
+[Hefstadtera likums Vikipēdijā](https://en.wikipedia.org/wiki/Hofstadter%27s_law)
+
+> Tas vienmēr aizņem vairāk laika, nekā jūs domājat, pat ņemot vērā Hofštera likumu.
+>
+> (Duglass Hofstadters)
+
+Jūs varētu dzirdēt, kā šis likums tiek pieminēts, skatoties uz aprēķiniem, cik ilgi kaut kas notiks. Šķiet, ka programmatūras izstrādes triks ir tāds, ka mēs nemēdzam precīzi novērtēt, cik ilgs laiks būs vajadzīgs, lai to paveiktu.
+
+Tas ir no grāmatas “[Gödel, Escher, Bahs: An Mūžīgais Zelta Breidijs](#lasīšanas-saraksts)”.
+
+Skatīt arī:
+
+- [Lasīšanas saraksts: Gödel, Escher, Baach: An Mūžīgais zelta Breids](#lasīšanas-saraksts)
+
+### Hutbera likums
+
+[Hutbera likums Vikipēdijā](https://en.wikipedia.org/wiki/Hutber%27s_law)
+
+> Uzlabošanās nozīmē nolietošanos.
+>
+> ([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber))
+
+Šis likums liek domāt, ka sistēmas uzlabojumi novedīs pie citu daļu pasliktināšanās vai arī apslēps citu pasliktināšanos, kas kopumā novedīs pie degradācijas no sistēmas pašreizējā stāvokļa.
+
+Piemēram, atbildes latentuma samazināšanās konkrētā galapunktā varētu radīt papildu caurlaidspējas un jaudas problēmas pieprasījuma plūsmā, ietekmējot pilnīgi citu apakšsistēmu.
+
+### Hype Cycle & Amara likums
+
+[Hype Cycle Vikipēdijā](https://en.wikipedia.org/wiki/Hype_cycle)
+
+> Mēs pārāk augstu vērtējam tehnoloģijas ietekmi īstermiņā un nepietiekami novērtējam tās ietekmi ilgtermiņā.
+>
+> (Rojs Amara)
+
+Hype Cycle ir Gārtnera sākotnēji ražotās tehnoloģijas saviļņojuma un attīstības vizuāls attēlojums laika gaitā. Vislabāk to rāda vizuāli:
+
+![The Hype Cycle](../images/gartner_hype_cycle.png)
+
+*(Atsauce uz attēlu: angļu valodā Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)*
+
+Īsāk sakot, šis cikls liecina, ka parasti rodas satraukums par jaunām tehnoloģijām un to iespējamo ietekmi. Komandas bieži vien ātri iesoļo šajās tehnoloģijās un reizēm jūtas vīlušās ar rezultātiem. Tas varētu būt tāpēc, ka tehnoloģija vēl nav pietiekami izstrādāta vai arī reālie lietojumi vēl nav pilnībā īstenoti. Pēc zināma laika tehnoloģijas iespējas palielinās un praktiskās iespējas to izmantot palielinās, un komandas beidzot var kļūt ražīgas. Rojs Amars (Roy Amara) citēja šo jautājumu visskaļāk: “Mums ir tendence pārvērtēt tehnoloģijas ietekmi īstermiņā un novērtēt to par zemu ilgtermiņā.”
+
+### Hiruma likums (Perifērisko saskarņu likums)
+
+[Hiruma likums Online](http://www.hyrumslaw.com/)
+
+> Ar pietiekamu API lietotāju skaitu,
+> nav svarīgi, ko jūs solāt līgumā:
+> visas novērojamās sistēmas darbības
+> būs atkarīgs no kāda.
+>
+> (Hyrum Wright)
+
+Hirum likums nosaka, ka tad, ja jums ir _pietiekami liels API patērētāju skaits_, visas API darbības (pat tās, kas nav definētas kā publiskā līguma daļa) galu galā būs atkarīgas no kāda. Triviāls piemērs var būt nefunkcionāli elementi, piemēram, API atbildes laiks. Smalkāks piemērs varētu būt patērētāji, kas paļaujas uz regex piemērošanu kļūdas ziņojumam, lai noteiktu API kļūdas *tipu*. Pat tad, ja API publiskajā līgumā nav norādīts ziņojuma saturs, norādot, ka lietotājiem jālieto saistītais kļūdas kods, _daži_ lietotāji var izmantot ziņojumu un, mainot ziņojumu, būtībā tiek pārtraukta API šiem lietotājiem.
+
+Skatīt arī:
+
+- [Leaky Abstractions likums](#the-law-of-dioxide-freshctions)
+- [XKCD 1172](https://xkcd.com/1172/)
+
+### Kernigana likums
+
+> Atkļūdošana ir divreiz smagāka nekā koda rakstīšana pirmajā vietā. Tāpēc, ja jūs uzrakstāt kodu pēc iespējas gudrāk, jūs pēc definīcijas neesat pietiekami gudrs, lai to atkļūdotu.
+>
+> (Brian Kernighan)
+
+Kernigana likums ir nosaukts [Brian Kernighan](https://en.wikipedia.org/wiki/Brian_Kernighan) un atvasināts no citāta no Kernighan un Plaugera grāmatas [Programmēšanas stila elementi](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style):
+
+> Visi zina, ka atkļūdošana ir divreiz smagāka nekā programmas rakstīšana. Tātad, ja tu esi tik gudrs, cik vari būt, kad tu to raksti, kā tu jebkad to atkļūsi?
+
+Lai gan Kernigana likums ir hiperbolisks, tas ir arguments, ka vienkāršam kodam ir jādod priekšroka attiecībā pret sarežģītu kodu, jo jebkuru sarežģītā koda jautājumu atkļūdošana var būt dārga vai pat neiespējama.
+
+Skatīt arī:
+
+- [KISS princips](#kiss-princips)
+- [Unix filozofija](#unix-filozofija)
+- [Occam's Razor](#occams-razor)
+
+### Metkalfa likums
+
+[Metkalfea likums Vikipēdijā](https://en.wikipedia.org/wiki/Metcalfe's_law)
+
+> Tīkla teorijā sistēmas vērtība pieaug aptuveni pēc sistēmas lietotāju skaita kvadrāta.
+
+Šis likums ir balstīts uz iespējamo pārtikušo savienojumu skaitu sistēmā un ir cieši saistīts ar [Reeda likums](#reeda-likums). Odlyzko un citi apgalvoja, ka gan Rīda likums, gan Metkalfa likums nosaka pārāk augstu sistēmas vērtību, neņemot vērā cilvēku izziņas robežas attiecībā uz tīkla ietekmi; skatīt [Danbara numurs](#dunbars-number).
+
+Skatīt arī:
+
+- [Reeda likums](#reeda-likums)
+- [Danbara numurs](#Danbara-numurs)
+
+### Mora likums
+
+[Mora likums Vikipēdijā](https://en.wikipedia.org/wiki/Moore%27s_law)
+
+> Tranzistoru skaits integrālajā shēmā divkāršojas aptuveni reizi divos gados.
+
+Mora prognozes ir ļoti precīzas no 1970. gadiem līdz pat 2000. gadu beigām. Pēdējos gados tendence ir nedaudz mainījusies, daļēji pateicoties [fiziskās robežas pakāpei, kādā komponentus var miniaturizēt](https://en.wikipedia.org/wiki/Quantum_tunnelling). Tomēr progress paralēlizācijā un, iespējams, revolucionāras izmaiņas pusvadītāju tehnoloģijā un kvantu skaitļošanā var nozīmēt, ka Mora likums varētu būt spēkā arī turpmākajos gadu desmitos.
+
+### Mērfija likums/Soda likums
+
+[Mērfija likums Vikipēdijā](https://en.wikipedia.org/wiki/Murphy%27s_law)
+
+> Jebkas, kas var noiet greizi, noies greizi.
+
+Saistībā ar [Edvards A. Mērfijs, Jr](https://en.wikipedia.org/wiki/Edward_A._Murphy_Jr.) _Mērfija likums_ teikts: ja kaut kas var noiet greizi, tas noies greizi.
+
+Tā ir vispārpieņemta izvēle izstrādātāju vidū. Dažreiz tas negaidītais notiek, attīstoties, testējot vai pat ražojot. Tas var būt saistīts arī ar (biežāk angļu valodā) _Sod's Law_:
+
+> Ja kaut kas var noiet greizi, tas notiks vissliktākajā laikā.
+
+Šos “likumus” parasti izmanto komiskā nozīmē. Tomēr tādas parādības kā [_Confirmation Bias_](#TODO) un [_Selection Bias_](#TODO) var likt cilvēkiem, iespējams, pārmērīgi uzsvērt šos likumus (lielākā daļa gadījumu, kad lietas darbojas, tās paliek nepamanītas, tomēr kļūmes ir pamanāmākas un rosina vairāk diskusiju).
+
+Skatīt arī:
+
+- [Bias apstiprinājums](#TODO)
+- [Bias atlases](#TODO)
+
+### Okuta Razors
+
+[Occam's Razor Vikipēdijā](https://en.wikipedia.org/wiki/Occam's_razor)
+
+> Entītijas nedrīkst reizināt bez nepieciešamības.
+>
+> Oklema Viljams
+
+Ouema skuveklis stāsta, ka starp vairākiem iespējamiem risinājumiem ticamākais risinājums ir tas, kuram ir vismazākais jēdzienu un pieņēmumu skaits. Šis risinājums ir vienkāršākais un atrisinās tikai dotā problēma, neieviešot nejaušu sarežģītību un iespējamās negatīvās sekas.
+
+Skatīt arī:
+
+- [YAGNI](#yagni)
+- [Bez sudraba aizzīme: hoc Compluncity and Essential Complexity](https://en.wikipedia.org/wiki/No_Silver_Bullet)
+
+Piemērs:
+- [prospect Software Development: Eliminate Waste laundering](https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste)
+
+### Parkinsona likums
+
+[Parkinsona likums Vikipēdijā](https://en.wikipedia.org/wiki/Parkinson%27s_law)
+
+> Darbs tiek izvērsts, lai aizpildītu laiku, kas ir pieejams tā pabeigšanai.
+
+Tā sākotnējā kontekstā šis likums balstījās uz birokrātijas pētījumiem. Tas var tikt pesimistiski piemērots programmatūras izstrādes iniciatīvām, jo teorija ir tāda, ka darba grupas būs neefektīvas līdz termiņa beigām, bet pēc tam steidzas pabeigt darbu līdz noteiktajam termiņam, tādējādi padarot faktisko termiņu nedaudz patvaļīgu.
+
+Ja šis likums tiktu apvienots ar [Hofštera likumu](#hofstadtera-likums), tad tiek panākts vēl pesimistiskāks viedoklis - darbs paplašināsies, lai aizpildītu tā pabeigšanai pieejamo laiku, un *joprojām paies ilgāk, nekā paredzēts*.
+
+Skatīt arī:
+
+- [Hofstadtera likums](#hofstadtera-likums)
+
+### Priekšlaicīgas optimizācijas efekts
+
+[Priekšlaicīga optimizācija WikiWikiWeb](http://wiki.c2.com/?PrematureOptimization)
+
+> Priekšlaicīga optimizācija ir visa ļaunuma sakne.
+>
+> [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en)
+
+Donalda Knuta (Donald Knuth) rakstā [Structured Programming With Go To Deements](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements) viņš rakstīja: „Programmeri tērē milzīgus laika apjomus, domājot par savu programmu nekritisko daļu ātrumu vai raizējoties par to, un šiem efektivitātes mēģinājumiem patiesībā ir liela negatīva ietekme, ja tiek apsvērta atkļūdošana un uzturēšana. Mums vajadzētu aizmirst par nelielu efektivitāti, teiksim par 97% no laika: **priekšlaicīga optimizācija ir visa ļaunuma sakne**. Tomēr mums nevajadzētu izmantot savas iespējas šajā būtiskajā 3%.”
+
+Tomēr _Premature Optimization_ var definēt (mazāk noslogotā izteiksmē) kā optimizāciju, pirms mēs zinām, ka tas ir nepieciešams.
+
+### Putta likums
+
+[Putta likums Vikipēdijā](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat)
+
+> Tehnoloģijā dominē divu veidu cilvēki, tie, kas saprot, ko nepārvalda, un tie, kas pārvalda to, ko nesaprot.
+
+Flowera likums bieži seko līdzi Putt Corollary:
+
+> katra tehniskā hierarhija laika gaitā attīsta kompetences neversiju.
+
+Šie paziņojumi liecina, ka, ņemot vērā dažādus atlases kritērijus un tendences attiecībā uz grupu organizāciju, būs daudz kvalificētu cilvēku tehniskās organizācijas darba līmenī un vairāki cilvēki vadošos amatos, kuri neapzinās viņu vadītā darba sarežģītību un problēmas. To var izraisīt tādas parādības kā [The Peter Principle](#the-peter-principle) vai [The Dilbert Principle](#the-dilbert-principle).
+
+Tomēr jāuzsver, ka šādi tiesību akti ir plaši vispārinājumi un var attiekties uz _dažiem_ organizāciju veidiem, nevis uz citiem.
+
+Skatīt arī:
+
+- [Peter Principle](#petera-princips)
+- [Dilberta princips](#dilberta-princips)
+
+### Reeda likums
+
+[Reeda likums Vikipēdijā](https://en.wikipedia.org/wiki/Reed's_law)
+
+> Lielo tīklu, it īpaši sociālo tīklu, lietderība ir atkarīga no tīkla lieluma.
+
+Šis likums balstās uz grafiku teoriju, kur lietderības mērogs ir kā iespējamo apakšgrupu skaits, kas ir ātrāks par dalībnieku skaitu vai iespējamo pārotāju savienojumu skaitu. Odlyzko un citi apgalvoja, ka Rīda likums nosaka sistēmas lietderību, nerēķinoties ar cilvēku izziņas ierobežojumiem attiecībā uz tīkla ietekmi; sk. [Danbara numurs](#Danbara-numurs).
+
+Skatīt arī:
+
+- [Metkalfa likums](#metkalfa-likums)
+- [Danbara numurs](#Danbara-numurs)
+
+### Taisnīguma saglabāšanas likums (Teslera likums)
+
+[Likums par stabilitātes saglabāšanu attiecībā uz Wikipedia](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity)
+
+Šis likums nosaka, ka sistēmā, kuru nevar samazināt, pastāv zināma sarežģītības pakāpe.
+
+Sistēmas sarežģītība ir “netīša”. Tās ir vājās struktūras, kļūdu vai tikai sliktas problēmas modelēšanas sekas. Nejaušu sarežģītību var samazināt (vai novērst). Tomēr, ņemot vērā problēmas sarežģītību, pastāv zināma sarežģītība. Šo sarežģītību var pārvietot, bet ne likvidēt.
+
+Viens no šā likuma interesantākajiem elementiem ir ieteikums, ka pat vienkāršojot visu sistēmu, netiek samazināta iekšējā sarežģītība, tas ir _jāpārvieto uz lietotāju_, kam jāuzvedas sarežģītāk.
+
+### “Leaky Abstractions” likums
+
+[The Law of Leaky Abstractions on Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-dioxide-freshctions/)
+
+> Visas netriviālās abstrakcijas zināmā mērā ir sūces.
+>
+> ([Joel Spolsky](https://twitter.com/spolsky))
+
+Šis likums nosaka, ka abstrakcijas, ko parasti izmanto skaitļošanā, lai vienkāršotu darbu ar sarežģītām sistēmām, noteiktās situācijās “noplūdīs” pamatsistēmas elementi, tādējādi padarot abstrakciju neparedzētu.
+
+Kā piemēru var minēt faila ielādi un tā satura lasīšanu. Failu sistēmas API ir zemāka līmeņa kodola sistēmu _abstrakcija_, kas pati par sevi ir abstrakcija pār fiziskajiem procesiem, kas saistīti ar datu maiņu magnētiskajā platē (vai zibatmiņu SSD). Vairumā gadījumu faila apstrāde kā bināro datu straume būs efektīva. Taču magnētiskajam diskam nolasāmie dati secīgi būs *ievērojami* ātrāki nekā brīvpiekļuves (jo palielinās lapu defektu pārsniegums), bet SSD diskdzinim šī pieskaitāmība nebūs. Lai risinātu šo gadījumu, būs jāizprot pamatinformācija (piemēram, datu bāzes indeksa faili ir strukturēti tā, lai samazinātu brīvpiekļuves pieskaitāmo daļu), bet izstrādātājam, iespējams, ir jāzina abstrakcijas “noplūžu” ieviešanas detaļas.
+
+Iepriekš minētais piemērs var kļūt sarežģītāks, ieviešot _vairāk_ abstrakciju. Operētājsistēma Linux ļauj piekļūt failiem, izmantojot tīklu, bet tā ir lokāli attēlota kā “parastie” faili. Šī abstrakcija “noplūdīs”, ja radīsies tīkla kļūmes. Ja izstrādātājs uzskata šos failus par “parastiem” failiem, neņemot vērā to, ka tie var būt pakļauti tīkla latentumam un kļūmēm, risinājumi būs neefektīvi.
+
+Tiesību aktu aprakstošais pants liecina, ka pārmērīga paļaušanās uz abstrakcijām apvienojumā ar vāju izpratni par pamatā esošajiem procesiem, atsevišķos gadījumos liek risināt šo problēmu _vairāk_ sarežģīti.
+
+Skatīt arī:
+
+- [Hyruma likums](#hyruma-likums-perifērisko-saskarņu-likums)
+
+Reālpasaules piemēri:
+
+- [Photoshop Slow Startup](https://forums.adobe.com/thread/376152) - problēma, ar kuru saskāros agrāk. Photoshop startēšana bija lēna, dažreiz tas prasīja dažas minūtes. Šķiet, problēma bija tā, ka startējot tas nolasa daļu informācijas par pašreizējo noklusējuma printeri. Tomēr, ja šis printeris faktiski ir tīkla printeris, tas var aizņemt ļoti ilgu laiku. Tīkla printera _abstrakcija_, kas tiek prezentēta sistēmai līdzīgi lokālajam printerim, radīja problēmas lietotājiem sliktā savienojamības situācijā.
+
+### Trivialitātes likums
+
+[Trivialitātes likums Vikipēdijā](https://en.wikipedia.org/wiki/Law_of_triviality)
+
+Šis likums liek domāt, ka grupas daudz vairāk laika un uzmanības veltīs triviāliem vai kosmētiskiem jautājumiem, nevis nopietniem un būtiskiem.
+
+Kopējais izdomātais piemērs ir komiteja, kas apstiprina plānus atomelektrostacijai, kura lielāko daļu laika pavada, apspriežot velosipēdistu nojumes struktūru, nevis pašu nozīmīgāko spēkstacijas projektu. Var būt grūti sniegt vērtīgu ieguldījumu diskusijās par ļoti lielām, komplicētām tēmām bez augstas kompetences vai sagatavotības. Tomēr cilvēki vēlas saņemt vērtīgu ieguldījumu. Tādēļ tendence pārāk daudz laika veltīt sīkumiem, par kuriem var viegli spriest, bet kuri ne vienmēr ir īpaši svarīgi.
+
+Iepriekš aprakstītais piemērs lika lietot terminu “Bike Shedding” kā izteicienu, lai izšķiestu laiku triviāliem sīkumiem. Saistītais termins ir “[Yak Shaving](https://en.wiktionary.org/wiki/yak_shaving)”, kas saista šķietami nebūtisku darbību, kas ir daļa no gara priekšnosacījumu ķēdes galvenajam uzdevumam.
+
+### Unix filozofija
+
+[Unix filozofija Vikipēdijā](https://en.wikipedia.org/wiki/Unix_philosophy)
+
+Unix filozofija ir tāda, ka programmatūras komponentiem jābūt maziem un jābūt vērstiem uz to, lai labi paveiktu vienu konkrētu lietu. Tas var atvieglot sistēmu izveidi, izveidojot kopā mazas, vienkāršas, labi definētas vienības, nevis izmantojot lielas, sarežģītas, daudzfunkcionālas programmas.
+
+Mūsdienu praksi, piemēram, "Microservice arhitektūru”, var uzskatīt par šī likuma piemērošanu, kur pakalpojumi ir mazi, koncentrēti un dara vienu konkrētu lietu, ļaujot kompleksai rīcībai veidot vienkāršus veidošanas blokus.
+
+### Spotify modelis
+
+[Spotify Model on Spotify Labs](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/)
+
+“Spotify” modelis ir pieeja komandas un organizācijas struktūrai, ko popularizē “Spotify”. Šajā modelī komandas tiek organizētas ap funkcijām, nevis tehnoloģijām.
+
+Spotify modelis popularizē arī Tribes, Guilds, Chapters jēdzienus, kas ir citi to organizācijas struktūras elementi.
+
+### Wadlera likums
+
+[Lunga likums on wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law)
+
+> jebkurā valodas dizainā kopējais laiks, kas pavadīts, apspriežot kādu līdzekli šajā sarakstā, ir proporcionāls diviem, kas izvirzīti tā atrašanās vietai.
+>
+> 0. Semantika
+> 1. Sintakse
+> 2. Leksiskā sintakse
+> 3. Komentāru leksiskā sintakse
+>
+> (īsāk sakot, par katru semantiku pavadīto stundu komentāru sintaksē tiks pavadītas 8 stundas).
+
+Līdzīgi kā [Trivialitātes likums](#trivialitātes-likums), Wadlera likums nosaka, ka, projektējot valodu, laika apjoms, kas tiek tērēts valodas konstrukcijām, ir nesamērīgi augsts salīdzinājumā ar šo iezīmju nozīmi.
+
+Skatīt arī:
+
+- [Trivialitātes likums](#trivialitātes-likums)
+
+### Wheaton likums
+
+[Saite](http://www.wheatonslaw.com/)[Oficiālā diena](https://dontbeadickday.com/)
+
+> Neesi stulbenis.
+>
+> _Wil Wheaton_
+
+Šī vienkāršā, lakoniskā un spēcīgā likuma mērķis ir palielināt harmoniju un cieņu profesionālajā organizācijā. To var izmantot, runājot ar kolēģiem, veicot koda pārskatīšanu, cīnoties pret citiem skatījumiem, kritizēšanu un kopumā lielāko daļu profesionālo mijiedarbību ar cilvēkiem.
+
+## Principi
+
+Parasti ir lielāka iespēja, ka principi ir pamatnostādnes, kas attiecas uz dizainu.
+
+### Dilberta princips
+
+[Dilberta princips Vikipēdijā](https://en.wikipedia.org/wiki/Dilbert_principle)
+
+> uzņēmumos tiek sistemātiski reklamēti nekompetenti darbinieki vadībai, lai tos izdabūtu no darbplūsmas.
+>
+> _Scott Adams_
+
+Vadības konceptu, ko izstrādājis Skots Adamss (Dilbert komiksu striptīza radītājs), Dilbert Princips iedvesmo [The Peter Principle](#the-peter-principle). Saskaņā ar Dilbert principu darbinieki, kas nekad nav bijuši kompetenti, tiek paaugstināti vadībā, lai ierobežotu kaitējumu, ko viņi var nodarīt. Adams vispirms izskaidroja šo principu 1995. gada “Wall Street Journal” rakstā un izvērsa to savā 1996. gada uzņēmējdarbības grāmatā [The Dilbert Principle](#lasīšanas-saraksts).
+
+Skatīt arī:
+
+- [Petera princips](#petera-princips)
+- [Putta likums](#putta-likums)
+
+### Pareto princips (kārtula 80/20)
+
+[Pareto Principle Vikipēdijā](https://en.wikipedia.org/wiki/Pareto_principle)
+
+> Vairums lietu dzīvē netiek sadalītas vienmērīgi.
+
+Pareto princips liecina, ka dažos gadījumos lielākā daļa rezultātu nāk no nelieliem ieguldījumiem:
+- 80% no noteiktas programmatūras var rakstīt 20% no kopējā piešķirtā laika (pretēji tam, visgrūtākie 20% no koda aizņem 80% laika).
+- 20% no piepūles veido 80% no rezultāta,
+- 20% no darba rada 80% no ieņēmumiem,
+- 20% atkritumu izraisa 80% avāriju
+- 20% līdzekļu izraisa 80% lietošanas
+
+1940. gadā amerikāņu un rumāņu inženieris doktors Džozefs Jurans (Joseph Juran), kurš plaši tiek ieskaitīts kā kvalitātes kontroles tēvs, sāka piemērot Pareto principu attiecībā uz kvalitātes jautājumiem (https://en.wikipedia.org/wiki/Joseph_M._Juran).
+
+Šis princips ir pazīstams arī kā 80/20 likums, Vital Few likums un The Principle of Factor Sparsity.
+
+Reālpasaules piemēri:
+
+- 2002. gadā korporācija Microsoft ziņoja, ka, fiksējot 20% lielāko visvairāk ziņoto kļūdu, tiks novērstas 80% saistīto kļūdu un avāriju logos un birojos ([Atsauce](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-'t-just-features.htm)).
+
+### Pētera princips
+
+[Peter Principle Vikipēdijā](https://en.wikipedia.org/wiki/Peter_principle)
+
+> Cilvēki hierarhijā tiecas sasniegt savu “nekompetences līmeni”.
+>
+> _Laurence J. Peter_
+
+Laurences J. Peteras (Peter Principle) izstrādātajā vadības koncepcijā norādīts, ka tiek reklamēti cilvēki, kas labi strādā savā darbavietā, līdz sasniedz līmeni, kurā viņi vairs nav veiksmīgi (viņu “nekompetences līmenis”. Šobrīd, tā kā viņi ir vecākie, ir mazāk ticams, ka viņi tiks izņemti no organizācijas (ja vien viņi nedarbosies īpaši slikti), un viņi turpinās strādāt tādā lomā, kurā viņiem ir maz iedzimtas prasmes, jo viņu sākotnējās prasmes, kas viņus padarījušas veiksmīgus, ne vienmēr ir vajadzīgas viņu jaunajiem darbiem.
+
+Tas jo īpaši interesē inženierus, kuri sākotnēji sāk pildīt ļoti tehniskas funkcijas, bet kuriem bieži vien ir karjeras ceļš, kas liek _vadīt_ citus inženierus, - kam ir nepieciešams būtiski atšķirīgs prasmju kopums.
+
+Skatīt arī:
+
+- [Dilberta princips](#dilberta-princips)
+- [Putta likums](#putta-likums)
+
+### Uzturības princips (Postel's Law)
+
+[Stabilitātes princips Vikipēdijā](https://en.wikipedia.org/wiki/Robustness_principle)
+
+> Esiet konservatīvi pret to, ko darāt, esiet liberāli tajā, ko pieņemat no citiem.
+
+Bieži lietots serveru lietojumprogrammu izstrādē, šis princips nosaka, ka tam, ko sūtāt citiem, ir jābūt pēc iespējas mazākam un atbilstošam, bet, ja to var apstrādāt, ir jācenšas atļaut nestandarta ievadi.
+
+Šā principa mērķis ir izveidot stabilas sistēmas, jo tās var izmantot vāju ieguldījumu, ja to vēl var saprast. Tomēr ir iespējamas sekas saistībā ar drošību, pieņemot nepareizi ievadītus datus, jo īpaši, ja šādu resursu apstrāde nav labi pārbaudīta.
+
+Ja laikus tiks pieļauta neatbilstība, protokola spēja attīstīties var mazināties, jo, lai veidotu savas iezīmes, īstenotāji, iespējams, paļausies uz šo liberalitāti.
+
+Skatīt arī:
+
+- [Hyruma likums](#hyruma-likums-perifērisko-saskarņu-likums)
+
+### SOLID
+
+Tas ir akronīms, kas attiecas uz:
+
+* S: [Vienotās atbildības princips](#vienotās-atbildības-princips)
+* O: [Atklātais/slēgtais princips](#atklātaisslēgtais-princips)
+* L: [Liskova aizstāšanas princips](#liskova-aizstāšanas-princips)
+* I: [Interfeisa segmenta noteikšanas princips](#interfeisa-segmenta-noteikšanas-princips)
+* D: [Atkarības inversijas princips](#atkarības-inversijas-princips)
+
+Šie ir galvenie principi programmā [Object-oriented Programming](#TODO). Projektēšanas principiem ir jābūt tādiem, kas var palīdzēt izstrādātājiem veidot labāk funkcionējošas sistēmas.
+
+### Vienotās atbildības princips
+
+[Vienotās atbildības princips Vikipēdiā](https://en.wikipedia.org/wiki/Single_responsibility_principle)
+
+> katram modulim vai klasei ir jābūt tikai vienai atbildībai.
+
+Pirmais no “[SOLID](#solid)” principiem. Šis princips liek domāt, ka moduļiem vai klasēm būtu jādara tikai viens un tikai viens. Praktiskāk tas nozīmē, ka, veicot vienu nelielu programmas līdzekļa maiņu, ir jāmaina tikai viens komponents. Piemēram, paroles validācijas sarežģītības dēļ ir jāmaina tikai viena programmas daļa.
+
+Teorētiski tam vajadzētu padarīt kodu spēcīgāku un vieglāk maināmu. Zinot, ka pārveidojamam komponentam ir tikai viena atbildība, tas nozīmē, ka _testēt_ šīs izmaiņas ir vieglāk. Izmantojot iepriekšējo piemēru, paroles sarežģītības komponenta maiņa var ietekmēt tikai ar paroles sarežģītību saistītos līdzekļus. Daudz grūtāk var būt pamatot pārmaiņu ietekmi uz komponentu, kam ir daudz pienākumu.
+
+Skatīt arī:
+
+- [Uz objektu vērsta programmēšana](#TODO)
+- [SOLID](#solid)
+
+### Open/Slēgts princips
+
+[Atklātais/slēgtais princips Vikipēdijā](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle)
+
+> entītijām jābūt atvērtām paplašinājumam un slēgtām modificēšanai.
+
+Otro no “[SOLID](#solid)” principiem. Šis princips nosaka, ka subjektiem (kas varētu būt klases, moduļi, funkcijas utt.) jābūt iespējai īstenot savu darbību _prolongēt_, bet to _esošo_ uzvedību nedrīkst mainīt.
+
+Kā hipotētisku piemēru iedomājieties moduli, kas var pārvērst Piezīmes dokumentu HTML formātā. Ja moduli varētu paplašināt, lai to varētu izmantot nesen ierosinātajai vērtības samazināšanas funkcijai, nemainot moduli, tas būtu atvērts paplašinājumam. Ja lietotājs varētu modificēt moduli _not_, lai ar to varētu rīkoties tagad, kad tiek apstrādāti esošie salīdzināšanas līdzekļi, tad tas būtu _slēgts_ modificēšanai.
+
+Šim principam ir īpaša nozīme attiecībā uz uz objektu vērstu programmēšanu, kur mēs varam projektēt objektus, lai tos varētu viegli paplašināt, bet mēs izvairītos no tādu objektu projektēšanas, kuru pašreizējā uzvedība var negaidīti mainīties.
+
+Skatīt arī:
+
+- [Uz objektu vērsta programmēšana](#TODO)
+- [SOLID](#solid)
+
+### Liskova aizstāšanas princips
+
+[Liskova aizstāšanas princips Vikipēdijā](https://en.wikipedia.org/wiki/Liskov_substitution_principle)
+
+> ir jābūt iespējai aizstāt tipu ar apakštipu, nelaužot sistēmu.
+
+Trešais no “[SOLID](#solid)” principiem. Šis princips nosaka, ka, ja kāds komponents balstās uz kādu tipu, tad tam vajadzētu būt iespējai izmantot šāda tipa apakštipus, bez sistēmas kļūmes vai informācijas par to, kas ir šis apakštips.
+
+Piemēram, iedomājieties, ka mums ir metode, kas nolasa XML dokumentu no struktūras, kas apzīmē failu. Ja metodē ir izmantots bāzes tips “fails”, funkcijā var izmantot jebko, kas izriet no “fails”. Ja 'fails' atbalsta meklēšanu atpakaļgaitā un XML parsētājs izmanto šo funkciju, bet atvasinātais tips 'tīkla fails' neizdodas, mēģinot veikt reverso meklēšanu, tad 'tīkla fails' pārkāptu principu.
+
+Šim principam ir īpaša nozīme uz objektu orientētā programmēšanā, kur tipa hierarhijas ir rūpīgi jāmodelē, lai izvairītos no sistēmas lietotāju apjukuma.
+
+Skatīt arī:
+
+- [Uz objektu vērsta programmēšana](#TODO)
+- [SOLID](#solid)
+
+### Interfeisa segmenta noteikšanas princips
+
+[Interfeisa segmenta noteikšanas princips Vikipēdijā](https://en.wikipedia.org/wiki/Interface_segregation_principle)
+
+> Neviens klients nedrīkst būt atkarīgs no metodēm, ko tas neizmanto.
+
+Ceturtā daļa no “[SOLID](#solid)” principiem. Šis princips nosaka, ka kāda komponenta patērētājiem nevajadzētu būt atkarīgiem no tā komponenta funkcijām, kuru tie faktiski neizmanto.
+
+Piemēram, iedomājieties, ka mums ir metode, kas nolasa XML dokumentu no struktūras, kas apzīmē failu. Tai tikai jālasa baiti, jāpārvietojas uz priekšu vai jāpārvietojas atpakaļ failā. Ja šī metode ir jāatjaunina, jo mainās ar failu struktūru nesaistīts faila struktūras līdzeklis (piemēram, faila drošības apzīmēšanai izmantotā atļauju modeļa atjauninājums), princips ir anulēts. Labāk būtu, ja fails ieviestu 'tries-stream' interfeisu un XML lasītājs to izmantotu.
+
+Šim principam ir īpaša nozīme uz objektu orientētajā programmēšanā, kur tiek izmantotas saskarnes, hierarhijas un abstrakti tipi, lai [minimizētu savienošanu](#TODO) starp dažādiem komponentiem. [pīļu tipizēšana](#TODO) ir metodika, kas ievieš šo principu, novēršot nepārprotamas saskarnes.
+
+Skatīt arī:
+
+- [Uz objektu vērsta programmēšana](#TODO)
+- [SOLID](#solid)
+- [pīļu tipēšana](#TODO)
+- [atsaiste](#TODO)
+
+### Atkarības inversijas princips
+
+[Atkarības inversijas princips](https://en.wikipedia.org/wiki/Dependency_inversion_principle)
+
+> Augsta līmeņa moduļi nedrīkst būt atkarīgi no zema līmeņa ieviešanas.
+
+Piektā daļa no “[SOLID](#solid)” principiem. Šis princips nosaka, ka lielāka līmeņa orķestrācijas komponentiem nav jāzina to atkarības detaļas.
+
+Piemēram, iedomājieties, ka mums ir programma, kas lasa metadatus no vietnes. Mēs pieņemam, ka galvenais komponents būtu jāzina par komponentu, lai lejupielādētu tīmekļa lapas saturu, pēc tam komponentu, kas var lasīt metadatus. Ja mēs ņemtu vērā atkarības inversiju, galvenais komponents būtu atkarīgs tikai no abstrakta komponenta, kas var iegūt baitu datus, un pēc tam no abstrakta komponenta, kas spētu nolasīt metadatus no baitu straumes. Galvenais komponents nezinātu par TCP/IP, HTTP, HTML utt.
+
+Šis princips ir sarežģīts, jo var šķist, ka tas "apgriež” sagaidāmās sistēmas (tātad nosaukuma) atkarības. Praksē tas nozīmē arī to, ka atsevišķam orķestrācijas komponentam ir jānodrošina abstrakto tipu pareiza ieviešana (piemēram, iepriekšējā piemērā _kaut kam_ joprojām ir jānodrošina metadatu lasītāja komponents HTTP faila lejupielādētājs un HTML metatagu lasītājs). Tas pieskaras tādiem modeļiem kā [Inversion of Control](#TODO) un [Atkarības injekcija](#TODO).
+
+Skatīt arī:
+
+- [Uz objektu vērsta programmēšana](#TODO)
+- [SOLID](#solid)
+- [Control inversija](#TODO)
+- [Atkarības injekcija](#TODO)
+
+### DRY princips
+
+[DRY princips Vikipēdijā](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)
+
+> Katram zināšanu gabalam ir jābūt vienotam, nepārprotamam, autoritatīvam attēlojumam sistēmā.
+
+DRY ir akronīms _Neatkārtot sevi_. Šī principa mērķis ir palīdzēt izstrādātājiem samazināt koda atkārtojumu un saglabāt informāciju vienā vietā, un 1999. gadā to citēja Endrū Bads un Deivs Tomass grāmatā [The Praietverot izstrādātāju](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+
+> PRETĒJS sausums būtu _WET_ (Rakstiet All Twice vai We Enjoy Typing).
+
+Praksē, ja jums ir viena un tā pati informācija divās (vai vairākās) dažādās vietās, varat izmantot DRY, lai sapludinātu tās vienā un atkārtoti izmantotu visur, kur vēlaties/vajag.
+
+Skatīt arī:
+
+- [Pracistic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+
+### KISS princips
+
+[KISS princips Vikipēdijā](https://en.wikipedia.org/wiki/KISS_principle)
+
+> saglabāt vienkāršu, stulbu
+
+KISS princips nosaka, ka vairums sistēmu darbojas vislabāk, ja tās ir vienkāršas, nevis sarežģītas; tāpēc vienkāršībai jābūt galvenajam mērķim, un jāizvairās no nevajadzīgas sarežģītības. Šī frāze, kuras izcelsme ir ASV Jūras kara flotē 1960. gadā, ir saistīta ar gaisa kuģu inženieri Kelliju Džonsonu.
+
+Šo principu vislabāk raksturo stāsts par to, ka Džonsons ir pasniedzis dizaina inženieru komandai sauju darbarīku, ar izaicinājumu, ka reaktīvo lidmašīnu, ko viņi projektēja, ir jālabo vidusmēra mehāniķim kaujas apstākļos ar tikai šiem rīkiem. Līdz ar to “muļķīgais” attiecas uz attiecību starp to, kā viss sabrūk, un to, cik sarežģīti ir instrumenti, kas ir pieejami, lai tos salabotu, nevis uz pašu inženieru spējām.
+
+Skatīt arī:
+
+- [Galla Likums](#galla-likums)
+
+### YAGNI
+
+[YAGNI Vikipēdijā](https://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it)
+
+Šis ir akronīms, kas paredzēts _**Y**ou **A**in't **G**onna **N**eed **I**t_.
+
+> vienmēr ieviesiet lietas, kad tās jums patiešām ir vajadzīgas, nekad neparedzot, ka jums tās ir nepieciešamas.
+>
+> ([Ron Jeffries](https://twitter.com/RonJeffries)) (XP līdzdibinātājs un grāmatas “Extreme Programming Installed” autors)
+
+Šis _Extreme Programming_ (XP) princips paredz, ka izstrādātājiem ir tikai jāievieš tūlītējām prasībām nepieciešamā funkcionalitāte un jāizvairās no mēģinājumiem prognozēt nākotni, ieviešot funkcionalitāti, kas varētu būt nepieciešama vēlāk.
+
+Ievērojot šo principu, būtu jāsamazina neizmantotā koda daudzums konvertācijā un jāizvairās no laika un pūles izniekošanas funkcionalitātei, kas nerada nekādu vērtību.
+
+Skatīt arī:
+
+- [Lasīšanas saraksts: Extreme Programming Installed](#lasīšanas-saraksts)
+
+### Dalītās datošanas maldības
+
+[Dalītās datošanas maldības Vikipēdijā](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing)
+
+Fallacies, ko dēvē arī par _Networking Computing_, ir Fallacies saraksts ar pieņēmumiem (vai uzskatiem) par dalīto skaitļošanu, kas var novest pie kļūmēm programmatūras izstrādē. Pieņēmumi ir šādi:
+
+- tīkls ir uzticams
+- latentums ir nulle
+- joslas platums ir bezgalīgs
+- tīkls ir drošs
+- topoloģija nemainās
+- ir viens administrators,
+- transporta izmaksas ir nulle
+- tīkls ir viendabīgs
+
+Pirmo četru pozīciju sarakstā bija iekļauti [Bill Joy](https://en.wikipedia.org/wiki/Bill_Joy) un [Tom Lyon](https://twitter.com/aka_pugs) aptuveni 1991. gadā, un tās pirmo reizi klasificēja [James Gosling](https://en.wikipedia.org/wiki/James_Gosling) kā “Networks Computing” Fallacies. [L. Peter Deutsch](https://en.wikipedia.org/wiki/L._Peter_Deutsch) pievienoja 5., 6. un 7. 90. gadu beigās Goslings pievienoja 8. maldu.
+
+Grupu iedvesmoja tas, kas tolaik notika [Sun Microsystems](https://en.wikipedia.org/wiki/Sun_Microsystems).
+
+Šīs kļūdas būtu rūpīgi jāapsver, izstrādājot kodu, kas ir elastīgs; pieņemot, ka kāds no šiem viltojumiem var novest pie kļūdainas loģikas, kas nerisina dalīto sistēmu realitāti un sarežģītību.
+
+Skatīt arī:
+
+- [Barošana dalītās datošanas maldības (1. daļa) — Vaidehi Jošipar vidēju](https://medium.com/baseds/foraging-for-the-fallacies-of-trapped-part-1-1b35c3b85b53)
+- [Deutsch's Fallacies, 10 years After](http://java.sys-con.com/node/38665)
+
+## Lasīšanas saraksts
+
+Ja šos jēdzienus esat uzskatījis par interesantiem, varat baudīt šādas grāmatas.
+
+- [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834).
+- [The Mythical Man Monthly - Frederik P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - Klasisks sējums par programmatūras inženieriju. [Brūku likums](#bruku-likums) ir grāmatas galvenā tēma.
+- [Gödel, Escher, Bahs: An Mūžīgais Zelta Breids - Duglass R. Hofštters.](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - Šo grāmatu ir grūti klasificēt. [hofstadtera likums](#hofstadtera-likums) ir no grāmatas.
+- [Dilberta princips - Scott Adams](https://www.goodreads.com/book/show/85574.The_Dilbert_Principle) - Komisks skats uz korporatīvo Ameriku, no autora, kurš radīja [Dilbert principu](#the-dilbert-principle).
+- [The Peter Principle - Lawrence J. Peter](https://www.goodreads.com/book/show/890728.The_Peter_Principle) - Vēl viens komisks skatījums uz lielāku organizāciju un tautas menedžmenta izaicinājumiem, [The Peter Principle](#the-peter-principle) avots.
+
+## Saistītie projekti
+
+- Dienas padoms - saņemiet ikdienas hakeru likumu/principu.
+
+## Ieguldījums
+
+Lūdzu, sniedziet ieguldījumu! [celiet problēmu](https://github.com/dwmkerr/hacker-laws/issues/new), ja vēlaties ierosināt papildinājumu vai izmaiņas, vai [Atvērt vilkšanas pieprasījumu](https://github.com/dwmkerr/hacker-law/compare), lai piedāvātu savas izmaiņas.
+
+Lūdzu, izlasiet [Ieguldījuma vadlīnijas](./.github/contributing.md) prasības par tekstu, stilu un tā tālāk. Iesaistoties diskusijās par projektu, lūdzu, ņemiet vērā [Uzvedības kodeksu](./.github/CODE_OF_CONDUCT.md).
+
+## TODO
+
+Sveiks! Ja jūs nolaisties šeit, jūs esat noklikšķinājis uz saites uz tēmu, kuru es vēl neesmu uzrakstījis, atvainojiet par to - šis ir darbs, kas notiek!
+
+Lai iesniegtu piedāvāto tēmas definīciju, varat [Raise an Issue](https://github.com/dwmkerr/hacker-law/issues) pieprasīt detalizētāku informāciju vai [Open a Pull Request](https://github.com/dwmkerr/hacker-laws/pull).

translations/pt-BR.md

@@ -1,11 +1,10 @@
 # 💻📖 hacker-laws
 
-Leis, Teorias, Principios e Padrões que desenvolvedores acham úteis.
+Leis, teorias, princípios e padrões que desenvolvedores acharão úteis.
 
-- 🇨🇳 [中文 / Versão Chinesa ](https://github.com/nusr/hacker-laws-zh) - Obrigado [Steve Xu](https://github.com/nusr)!
+[Traduções](#translations): [🇮🇩](./translations/pt-BR.md) [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇩🇪](./translations/de.md) [🇫🇷](./translations/fr.md) [🇬🇷](./translations/el.md) [🇮🇹](https://github.com/csparpa/hacker-laws-it) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](https://github.com/umutphp/hacker-laws-tr) [🇯🇵](./translations/jp.md)
-- 🇰🇷 [한국어 / Versão Koreana](https://github.com/codeanddonuts/hacker-laws-kr) - Obrigado [Doughnut](https://github.com/codeanddonuts)!
+
-- 🇷🇺 [Русская версия / Versão Russa](https://github.com/solarrust/hacker-laws) - Obrigado [Alena Batitskaya](https://github.com/solarrust)!
+Gostou deste projeto? Por favor, considere [me apoiar](https://github.com/sponsors/dwmkerr) e [apoiar os tradutores](#traduções).
-- 🇹🇷 [Türkçe / Versão Turka](https://github.com/umutphp/hacker-laws-tr) - Obrigado [Umut Işık](https://github.com/umutphp)
 
 ---
 
@@ -13,58 +12,90 @@ Leis, Teorias, Principios e Padrões que desenvolvedores acham úteis.
 
 * [Introdução](#introdução)
 * [Leis](#leis)
-    * [Lei De Amdahl](#lei-de-amdahl)
+  * [Princípio 90-9-1 (Regra do 1%)](#princípio-90-9-1-regra-do-1)
+  * [Lei de Amdahl](#lei-de-amdahl)
+  * [Teoria das Janelas Quebradas](#teoria-das-janelas-quebradas)
   * [Lei de Brook](#lei-de-brook)
   * [Lei de Conway](#lei-de-conway)
+  * [Lei de Cunningham](#lei-de-cunningham)
   * [Número de Dunbar](#número-de-dunbar)
+  * [Lei de Gall](#lei-de-gall)
+  * [Lei de Goodhart](#lei-de-goodhart)
   * [Navalha de Hanlon](#navalha-de-hanlon)
   * [Lei de Hofstadter](#lei-de-hofstadter)
+  * [Lei de Hutber](#lei-de-hutber)
   * [O Ciclo Hype e Lei de Amara](#o-ciclo-hype-e-lei-de-amara)
-    * [Lei de Hyrum (A lei de interfaces implicitas)](#lei-de-hyrum-a-lei-de-interfaces-implicitas)
+  * [Lei de Hyrum (Lei das Interfaces Implícitas)](#lei-de-hyrum-lei-das-interfaces-implícitas)
+  * [Lei de Kernighan](#lei-de-kernighan)
+  * [Lei de Metcalfe](#lei-de-metcalfe)
   * [Lei de Moore](#lei-de-moore)
+  * [Lei de Murphy / Lei de Sod](#lei-de-murphy--lei-de-sod)
+  * [Navalha de Occam](#navalha-de-occam)
   * [Lei de Parkinson](#lei-de-parkinson)
+  * [Efeito de Otimização Prematura](#efeito-de-otimização-prematura)
   * [Lei de Putt](#lei-de-putt)
-    * [A lei da Conservação de Complexidade (Lei de Tesler)](#a-lei-da-conservação-de-complexidade-lei-de-tesler)
+  * [Lei de Reed](#lei-de-reed)
-    * [A lei das Abstrações gotejantes](#a-lei-das-abstrações-gotejantes)
+  * [A Lei da Conservação da Complexidade (Lei de Tesler)](#a-lei-da-conservação-da-complexidade-lei-de-tesler)
-    * [The Law of Triviality](#the-law-of-triviality)
+  * [A Lei das Abstrações Gotejantes](#a-lei-das-abstrações-gotejantes)
-    * [The Unix Philosophy](#the-unix-philosophy)
+  * [A Lei da Trivialidade](#a-lei-da-trivialidade)
-    * [The Spotify Model](#the-spotify-model)
+  * [A Filosofia Unix](#a-filosofia-unix)
-    * [Wadler's Law](#wadlers-law)
+  * [O Modelo Spotify](#o-modelo-spotify)
-* [Principles](#principles)
+  * [Lei de Wadler](#lei-de-wadler)
-    * [The Pareto Principle (The 80/20 Rule)](#the-pareto-principle-the-8020-rule)
+  * [Lei de Wheaton](#lei-de-wheaton)
-    * [The Robustness Principle (Postel's Law)](#the-robustness-principle-postels-law)
+* [Princípios](#princípios)
+  * [O Princípio Dilbert](#o-princípio-dilbert)
+  * [O Princípio de Pareto (Regra do 80/20)](#o-princípio-de-pareto-regra-do-8020)
+  * [O Princípio de Peter](#o-princípio-de-peter)
+  * [O Princípio da Robustez (Lei de Postel)](#o-princípio-da-robustez-lei-de-postel)
   * [SOLID](#solid)
-    * [The Single Responsibility Principle](#the-single-responsibility-principle)
+  * [O Princípio da Responsabilidade Única](#o-princípio-da-responsabilidade-única)
-    * [The Open/Closed Principle](#the-openclosed-principle)
+  * [O Princípio do Aberto/Fechado](#o-princípio-do-abertofechado)
-    * [The Liskov Substitution Principle](#the-liskov-substitution-principle)
+  * [O Princípio da Substituição de Liskov](#o-princípio-da-substituição-de-liskov)
-    * [The Interface Segregation Principle](#the-interface-segregation-principle)
+  * [O Princípio da Segregação de Interface](#o-princípio-da-segregação-de-interface)
-    * [The Dependency Inversion Principle](#the-dependency-inversion-principle)
+  * [O Princípio da Inversão de Dependência](#o-princípio-da-inversão-de-dependência)
-    * [The DRY Principle](#the-dry-principle)
+  * [O Princípio DRY](#o-princípio-dry)
+  * [O Princípio KISS](#o-princípio-kiss)
   * [YAGNI](#yagni)
-* [Lista de Livros](#lista-de-livros)
+  * [As Falácias da Computação Distribuída](#as-falácias-da-computação-distribuída)
-* [Em Progresso](#em-progresso)
+* [Lista de leitura](#lista-de-leitura)
+* [Traduções](#traduções)
+* [Projetos relacionados](#projetos-relacionados)
+* [Contribuindo](#contribuindo)
+* [Em construção](#em-construção)
 
 <!-- vim-markdown-toc -->
 
 ## Introdução
 
-Existem muitas leis que as pessoas discutem quando falam sobre desenvolvimento. Esse repositório é uma referencia e uma visão global dos mais comuns. Sinta-se a vontade para contribuir e compartilhar.
+Existem muitas leis sobre as quais as pessoas discutem quando falam sobre desenvolvimento. Este repositório é uma referência e uma visão global das mais comuns. Sinta-se a vontade para contribuir e compartilhar.
 
-<!--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! <!-->
+❗: Este repositório contém explicações sobre algumas leis, princípios e padrões, mas não _advoga_ nenhum. Se eles devem ser aplicados é uma questão de discussão, e depende diretamente no que você está trabalhando.
-
-❗: Esse repositório contém explicações sobre algumas léis, pincípios e padrões, mas não _advoca_ para nenhum. Se eles devem ser aplicados sempre é uma questão de debate, e depende diretamente no que você está trabalhando.
 
 ## Leis
 
-Lá vamos nós!!
+E lá vamos nós!
 
-### Lei De Amdahl
+### Princípio 90-9-1 (Regra do 1%)
 
-[Lei de Amdahl na Wikipedia](https://pt.wikipedia.org/wiki/Lei_de_Amdahl)
+[1% Rule on Wikipedia](https://en.wikipedia.org/wiki/1%25_rule_(Internet_culture))
+
+O Princípio 90-9-1 sugere que em uma comunidade da internet, como uma wiki, 90% dos participantes apenas consomem o conteúdo, 9% editam ou modificam o conteúdo e 1% dos participantes adicionam novos conteúdos.
+
+Exemplos do mundo real:
+
+- Um estudo de 2014 de quatro redes sociais de saúde digital concluíram que 1% dos usuários criaram 73% das publicações, os próximos 9% foram responsáveis por cerca de ~25% e os 90% restantes por uma média de 2% ([Referência](https://www.jmir.org/2014/2/e33/))
+
+Veja também:
+
+- [O Princípio de Pareto (Regra do 80/20)](#o-princípio-de-pareto-regra-do-8020)
+
+### Lei de Amdahl
+
+[Lei de Amdahl na Wikipédia](https://pt.wikipedia.org/wiki/Lei_de_Amdahl)
 
 > A lei de Amdahl, também conhecida como argumento de Amdahl, é usada para encontrar a máxima melhora esperada para um sistema em geral quando apenas uma única parte do mesmo é melhorada. Isto é frequentemente usado em computação paralela para prever o máximo speedup teórico usando múltiplos processadores. A lei possui o nome do Arquiteto computacional Gene Amdahl, e foi apresentada a AFIPS na Conferência Conjunta de Informática na primavera de 1967.
 
-Fica mais fácil de entender com um exemplo prático. Se um programa é feito de duas partes, parte A, que é executada por um processador único, e parte B, que pode ser feito paralelamente com N processadores. Se adicionarmos mais processaores ao sistema, só vai ter aumento nas tarefas relacionadas à parte B do programa. A velocidade de A se mantém a mesma.
+Fica mais fácil de entender com um exemplo prático. Se um programa é feito de duas partes, parte A, que é executada por um processador único, e parte B, que pode ser feito paralelamente com N processadores. Se adicionarmos mais processadores ao sistema, só vai ter aumento nas tarefas relacionadas à parte B do programa. A velocidade de A se mantém a mesma.
 
 O diagrama abaixo mostra alguns exemplos de melhoria na velocidade:
 
@@ -74,17 +105,33 @@ O diagrama abaixo mostra alguns exemplos de melhoria na velocidade:
 
 Como pode-se perceber, mesmo um programa que teve metade da sua implementação de forma paralela, o benefício é menos de 10 _processing units_. Porém, um programa 95% paralelo, o ganho pode passar de 20 _processing units_.
 
+### Teoria das Janelas Quebradas
+
+[The Broken Windows Theory on Wikipedia](https://en.wikipedia.org/wiki/Broken_windows_theory)
+
+A Teoria das Janelas Quebradas sugere que sinais visíveis de crimes (ou a falta de cuidado por um ambiente) leva a crimes mais sérios (ou mais deterioração do ambiente).
+
+Essa teoria tem sido aplicada no desenvolvimento de software, sugerindo que a baixa qualidade do código (ou o [Débito Técnico](#TODO)) podem levar a percepção de que esforços para melhorar a qualidade talvez sejam ignorados ou desvalorizados, mantendo a baixa qualidade. Esse efeito de cascata leva a uma grande diminuição na qualidade através do tempo.
+
+Veja também:
+
+- [Débito Técnico](#TODO)
+
+Exemplos:
+
+- [The Pragmatic Programming: Software Entropy](https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy)
+- [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/)
+
 ### Lei de Brook
 
-[Lei de Brooks na Wikipeia](https://en.wikipedia.org/wiki/Brooks%27s_law)
+[Lei de Brooks na Wikipedia](https://en.wikipedia.org/wiki/Brooks%27s_law)
 
+> Adicionar recursos humanos em um projeto, de desenvolvimento de software, atrasado, faz ficar ainda mais atrasado.
 
-> Adicionar recursos humanos em um projeto, de desenvolvimento de sotware, atrasado, faz ficar ainda mais atrasado. 
+Essa lei sugere que em muitos casos, na tentativa de acelerar uma entrega, que já está atrasada, adicionando mais pessoas atrasa ainda mais essa entrega. Brooks assume que essa afirmação é uma generalização excessiva, entretanto, o principal motivo para isso acontecer é dado pelo simples fato de adicionar pessoas requer um gasto com comunicação e construção de novos recursos para a equipe suportar novos membros. Logo, a curto prazo esse investimento não tem um retorno. Também existem tarefas que não podem ser dividias, portanto adicionar mais pessoas não vai fazer ela ser concluída mais rápido.
-
-Essa lei sugere que em muitos casos, na tentativa de acelerar uma entrega, que já está atrasada, adcionando mais pessoas atrasa ainda mais essa entrega. Brooke assume que essa afirmação é uma generalização excessiva, entretanto, o principal motivo para isso acontecer é dado pelo simples fato de adicionar pessoas requer um gasto com comunicação e construção de novos recursos para a equipe suportar novos membros. Logo, a curto prazo esse investimento não tem um retorno. Também existem tarefas que não podem ser dividias, portanto adicionar mais pessoas não vai fazer ela ser concluida mais rápido. 
-
-"Nove mulheres não podem parir uma criança em um mês" e "Dois pilotos não fazem o carro ir mais rápido" são frases relacionadas a Lei de Brooke, principalmente porque algumas tarefas nao podem ser divididas.
 
+"Nove mulheres não podem parir uma criança em um mês" e "Dois pilotos não fazem o carro ir mais rápido" são frases relacionadas a Lei de Brooks, principalmente porque algumas tarefas não podem ser divididas.
 
 Esse é um tema central do livro '[The Mythical Man Month](#lista-de-livros)'.
 
@@ -97,25 +144,76 @@ Veja também:
 
 [Lei de Conway na wikipedia](https://en.wikipedia.org/wiki/Conway%27s_law)
 
-Essa lei sugere que limites técnicos de um sistema refletirão na estrutura da organização. Se uma organização é estruturada em pequenos setores, desconexas unidades, o sofware que ela produz sera assim também. Se uma organização é construida de forma vertical, em torno de funcionalidades e serviços, terá reflexo disso dentro do sistema.
+Essa lei sugere que limites técnicos de um sistema refletirão na estrutura da organização. Se uma organização é estruturada em pequenos setores, desconexas unidades, o software que ela produz sera assim também. Se uma organização é construída de forma vertical, em torno de funcionalidades e serviços, terá reflexo disso dentro do sistema.
 
 Veja também:
 
 - [Modelo do Spotify](#modelo-spotify)
 
+### Lei de Cunnigham
+
+[Cunningham's Law on Wikipedia](https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham's_Law)
+
+> A melhor forma de obter a resposta correta na Internet não é fazer a pergunta, mas postar a resposta errada.
+
+De acordo com Steven McGeady, Ward Cunningham o aconselhou no início dos anos 80: "A melhor forma de ter a resposta correta na Internet não é fazer a pergunta, mas postar a resposta errada." McGeady apelidou essa lei de "Lei de Cunningham", mesmo que Cunningham negue sua propriedade chamando-a de "citação". Mesmo originalmente se referindo a interações na Usenet, a lei tem sido utilizada para descrever como comunidades online funcionam (e.x.: Wikipedia, Reddit, Twitter, Facebook).
+
+Veja também:
+
+- [XKCD 386: "Duty Calls"](https://xkcd.com/386/)
+
 ### Número de Dunbar
 
 [Número de Dunbar na Wikipedia](https://en.wikipedia.org/wiki/Dunbar%27s_number)
 
-[Dumbar] propós que humanos só conseguem manter de forma confortável, 150 relacionamentos estáveis. Esse número está mais em um contexto social, "o número de pessoas que você não se sentiria sem graça para se juntar em uma bebiba se esbarrase com ela em um bar". Esse número geralmente está entra 100 e 250.
+Dunbar propôs que humanos só conseguem manter de forma confortável, 150 relacionamentos estáveis. Esse número está mais em um contexto social, "o número de pessoas que você não se sentiria sem graça para se juntar em uma bebida se esbarrasse com ela em um bar". Esse número geralmente está entra 100 e 250.
 
-Esse número é uma sugestão cognitiva limite para o número de pessoass para qual consegue-se manter uma relação social estável.
+Esse número é uma sugestão cognitiva limite para o número de pessoas para qual consegue-se manter uma relação social estável.
 
-Como uma relação entre pessoas, manter uma relação entre desenvolvedor e codigo requer esforço. É necessário usar politicas, padrões e procedimentos para encarar projetos complicados ou qualquer adversidade possível nesse tipo de relação. Número de Dunbar é importante em vários aspectos, não somente quando a empresa está em crescimento, mas também ao definir o escopo para os esforços da equipe ou decidir quando u msistema deve investir em ferramentas para axuliar na sobrecarga da logística. Colocando em contexto de engrenharia, é o número de projetos para os quais você se sentiria confiante para ingresssar em uma rotação de plantão de suporte.
+Como uma relação entre pessoas, manter uma relação entre desenvolvedor e código requer esforço. É necessário usar politicas, padrões e procedimentos para encarar projetos complicados ou qualquer adversidade possível nesse tipo de relação. Número de Dunbar é importante em vários aspectos, não somente quando a empresa está em crescimento, mas também ao definir o escopo para os esforços da equipe ou decidir quando um sistema deve investir em ferramentas para auxiliar na sobrecarga da logística. Colocando em contexto de engrenharia, é o número de projetos para os quais você se sentiria confiante para ingressar em uma rotação de plantão de suporte.
 
 Veja também:
 
-- [Lei de Conwy](#lei-de-conway)
+- [Lei de Conway](#lei-de-conway)
+
+### Lei de Gall
+
+[Gall's Law on Wikipedia](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law)
+
+> Um sistema complexo que funciona é invariavelmente encontrado para ter evoluído a partir de um sistema simples que trabalhou. Um sistema complexo projetado a partir do zero nunca funciona e não pode ser remendado para fazê-lo funcionar.
+
+A Lei de Gall afirma que tentativas de projetar sistemas altamente complexos provavelmente falharão. Sistemas altamente complexos raramente são construídos em uma vez só, mas evoluem a partir de sistemas mais simples.
+
+Um exemplo clássico é a world-wide-web. Em seu estado atual, ela é um sistema altamente complexo. Contudo, ela foi definida inicialmente como uma forma simples de compartilhar conteúdo entre instituições acadêmicas. Ela foi tão bem-sucedida em atingir esses objetivos que evoluiu para se tornar algo mais complexo ao longo do tempo.
+
+Veja também:
+
+- [KISS (Keep It Simple, Stupid)](#o-princípio-kiss)
+
+### Lei de Goodhart
+
+[The Goodhart's Law on Wikipedia](https://en.wikipedia.org/wiki/Goodhart's_law)
+
+> Qualquer regularidade estatística observada tende a entrar em colapso quando a pressão é aplicada para fins de controle.
+>
+> _Charles Goodhart_
+
+
+Também referenciada como:
+
+> Quando uma medida torna-se uma meta (ou alvo), ela deixa de ser uma boa medida.
+>
+> _Marilyn Strathern_
+
+A lei diz que otimizações orientadas por medidas podem levar à uma desvalorização do próprio resultado da medição. O conjunto de medidas excessivamente seletivo ([KPIs](https://en.wikipedia.org/wiki/Performance_indicator)) aplicado cegamente a um processo resulta em um efeito distorcido. As pessoas tentem a otimizar localmente "jogando com" o sistema para satisfazer métricas específicas ao invés de prestar atenção ao resultado holístico de suas ações.
+
+Exemplos do mundo real:
+- Testes sem `assertions` atendem à cobertura de código esperada, apesar do objetivo da métrica era criar software bem testado
+- A pontuação do desempenho de desenvolvedores é indicada pelo número de linhas `commitadas` leva a uma base de código injustificadamente inchada.
+
+Veja também:
+- [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)
 
 ### Navalha de Hanlon
 
@@ -125,9 +223,7 @@ Veja também:
 >
 > Robert J. Hanlon
 
-Esse principio sugeste que ações negativas não são sempre resultado de má vontade. Em vez disso, é mais provável que o resultado negativo seja atribuido à ações que não foram totalmente entendidas.
+Esse principio sugere que ações negativas não são sempre resultado de má vontade. Em vez disso, é mais provável que o resultado negativo seja atribuído à ações que não foram totalmente entendidas.
-
-
 
 ### Lei de Hofstadter
 
@@ -142,10 +238,21 @@ Você já deve ter ouvido sobre essa lei quando se fala em estimar tempo para fa
 
 This is from the book '[Gödel, Escher, Bach: An Eternal Golden Braid](#lista-de-livros)'.
 
+### Lei de Hutber
+
+[Hutber's Law on Wikipedia](https://en.wikipedia.org/wiki/Hutber%27s_law)
+
+> Melhoria significa deterioração.
+>
+> _([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber))_
+
+Essa lei sugere que melhorias em um sistema irão levar à deterioração em outras partes, ou elas ocultarão outras deteriorações, levando a uma degradação do estado atual do sistema.
+
+Por exemplo, a diminuição na latência da resposta para um `end-point` particular pode causar um aumento na taxa de transferência e na capacidade ao longo de um fluxo de solicitação, afetando um subsistema totalmente diferente.
+
 
 ### O Ciclo Hype e Lei de Amara
 
-
 [The ciclo Hype on Wikipedia](https://en.wikipedia.org/wiki/Hype_cycle)
 
 > Nós tendemos a superestimar os efeitos da tecnologia em curto prazo e subestimar os efeitos a longo prazo.
@@ -157,30 +264,61 @@ O Ciclo Hype é uma representação visual da empolgação e desenvolvimento da
 
 *(Image Reference: By Jeremykemp at English Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)*
 
-Em curto prazo, o cilco sugere que acontece uma explosão de empolgação a cerca de uma nova tecnologia e seu impácto em potencial. Equipes geralmente entram juntas nessas tecnlogias de forma rápida e em alguns casos ficam desapontados com os resutados. Uma das possíveis causas para isso é o fato da tecnologia em questão não ser madura o suficiente, ou aplicações do mundo real não estão totalmente prontas. Depois de um certo tempo, a capacidade da tecnologia aumenta e oportunidades práticas para uso dela aumentam, as equipes finalmente podem ser produtivos. A citação de Amara resume isso de forma sucinta - "Nós tendemos a superestimar os efeitos da tecnologia em curto prazo e subestimar os efeitos a longo prazo".
+Em curto prazo, o ciclo sugere que acontece uma explosão de empolgação a cerca de uma nova tecnologia e seu impacto em potencial. Equipes geralmente entram juntas nessas tecnologias de forma rápida e em alguns casos ficam desapontadas com os resultados. Uma das possíveis causas para isso é o fato da tecnologia em questão não ser madura o suficiente, ou aplicações do mundo real que não estão totalmente prontas. Depois de um certo tempo, a capacidade da tecnologia aumenta e oportunidades práticas para uso dela aumentam, as equipes finalmente podem ser produtivas. A citação de Amara resume isso de forma sucinta - "Nós tendemos a superestimar os efeitos da tecnologia em curto prazo e subestimar os efeitos a longo prazo".
 
 
-### Lei de Hyrum (A lei de interfaces implicitas)
+### Lei de Hyrum (Lei das Interfaces Implícitas)
 
 [Lei de Hyrum site](http://www.hyrumslaw.com/)
 
-
 > Com um número suficientes de clientes de uma API,
 > não importa a sua pré-condição no contato:
 > todos os comportamentos observáveis do seu sistema
 > serão dependentes de alguém.
 >
-> (Hyrum Wright)
+> Hyrum Wright
 
-A lei de Hyrum sugere que quando voce tem um número muito grande de consumidores de uma API, todos os comportamentos dessa API(mesmo aqueles que não estão definidos como parte de um contrato público) eventualmente irão dependender de outra parte do sistema, ou outra API. Um exemplo trivial pode ser elementos não funcionais, como o tempo de resposta de uma API. Um exemplo mais sutil pode ser os consumidores que estão confiando em aplicar um regex a uma mensagem de erro para determinar o _tipo_ de erro de uma API. Mesmo que o contrato público da API não especifique nada sobre o conteúdo da mensagem, indicando que os usuários devem usar um código de erro associado, alguns usuários podem usar a mensagem e alterar a mensagem essencialmente interrompe a API para esses usuários.
+A lei de Hyrum sugere que quando você tem um número muito grande de consumidores de uma API, todos os comportamentos dessa API (mesmo aqueles que não estão definidos como parte de um contrato público) eventualmente irão depender de outra parte do sistema, ou outra API. Um exemplo trivial pode ser elementos não funcionais, como o tempo de resposta de uma API. Um exemplo mais sutil pode ser os consumidores que estão confiando em aplicar um regex a uma mensagem de erro para determinar o _tipo_ de erro de uma API. Mesmo que o contrato público da API não especifique nada sobre o conteúdo da mensagem, indicando que os usuários devem usar um código de erro associado, alguns usuários podem usar a mensagem e alterar a mensagem essencialmente interrompe a API para esses usuários.
 
 Veja Também:
 
 - [XKCD 1172](https://xkcd.com/1172/)
 
+
+### Lei de Kernighan
+
+> A depuração é duplamente mais difícil do que escrever o código em primeiro lugar. Portanto, se você escrever o código da maneira mais inteligente possível, por definição, você não é inteligente o suficiente para depurá-lo.
+>
+> Brian Kernighan
+
+A Lei de Kerningham é nomeada por [Brian Kernighan](https://en.wikipedia.org/wiki/Brian_Kernighan) e derivada de uma citação de Kerningham no livro [The Elements of Programming Style](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style):
+
+> Todo mundo sabe que depurar é duplamente mais difícil do que programar em primeiro lugar. Então, se você é o mais inteligente possível quando escreve, como você conseguirá depurar o código?
+
+Enquanto hiperbólica, a Lei de Kerningham faz a argumentação de que código simples deve ser preferido ao invés de código complexo, porque depurar qualquer problema que poderá surgir em um código complexo pode ser custoso ou até mesmo inviável.
+
+Veja também:
+
+- [Princípio KISS](#o-princípio-kiss)
+- [Filosofia Unix](#a-filosofia-unix)
+- [Navalha de Occam](#navalha-de-occam)
+
+
+### Lei de Metcalfe
+
+[Metcalfe's Law on Wikipedia](https://en.wikipedia.org/wiki/Metcalfe's_law)
+
+> Na teoria das redes, o valor de um sistema cresce aproximadamente o quadrado do número de usuários daquele sistema.
+
+Esta lei é baseada no número de possíveis conexões pareadas dentro de um sistema e é relacionada com a [Lei de Reed](#lei-de-reed). Odlyzko e outros argumentaram que tanto a Lei de Reed e a Lei de Metcalfe exageram o valor do sistema, não levando em consideração os limites da cognição humana sobre os efeitos da rede; veja [Número de Dunbar](#número-de-dunbar).
+
+Veja também:
+- [Lei de Reed](#lei-de-reed)
+- [Número de Dunbar](#número-de-dunbar)
+
 ### Lei de Moore
 
-[Lei de Moore na wikipedia](https://en.wikipedia.org/wiki/Moore%27s_law)
+[Lei de Moore na Wikipedia](https://en.wikipedia.org/wiki/Moore%27s_law)
 
 > O número de transistores dentro de um circuito integrado dobra a cada 2 anos, aproximadamente.
 
@@ -191,6 +329,44 @@ Esta lei serve de parâmetro para uma elevada gama de dispositivos digitais, al
 
 Esse padrão continuou a se manter, e não se espera que pare até, no mínimo, 2021.
 
+### Lei de Murphy / Lei de Sod
+
+[Murphy's Law on Wikipedia](https://en.wikipedia.org/wiki/Murphy%27s_law)
+
+> Tudo que poderá dar errado, irá dar errado.
+
+Relacionada com [Edward A. Murphy, Jr](https://en.wikipedia.org/wiki/Edward_A._Murphy_Jr.), a _Lei de Murphy_ diz que se algo pode dar errado, isso dará errado.
+
+Isso é um ditado comum entre desenvolvedores. Muitas vezes o inesperado ocorre durante o desenvolvimento, testes ou até mesmo em produção. Essa lei também pode ser relacionada a Lei de Sod (mais comum no inglês britânico):
+
+> Se algo pode dar errado, dará errado, no pior momento possível.
+
+Essas 'leis' são geralmente utilizadas em um sentido cômico. Contudo, fenômenos como [_Confirmation Bias_](#TODO) e [_Selection Bias_](#TODO) podem levar as pessoas a enfatizarem demais essas leis (na maioria das vezes quando as coisas funcionam, elas passam desapercebidas, as falhas são mais perceptíveis e atraem mais discussões).
+
+Veja também:
+
+- [Confirmation Bias](#TODO)
+- [Selection Bias](#TODO)
+
+### Navalha de Occam
+
+[Navalha de Occam on Wikipedia](https://en.wikipedia.org/wiki/Occam's_razor)
+
+> Entidades não devem ser multiplicadas sem necessidade.
+>
+> William of Ockham
+
+A Navalha de Occam diz que em meio a várias possíveis soluções, a solução mais provável é aquela com menor número de conceitos e suposições. Essa solução é a mais simples e envolve apenas o problema em questão, sem introduzir complexidades acidentais e possíveis consequências negativas.
+
+Veja também:
+
+- [YAGNI](#yagni)
+- [No Silver Bullet: Accidental Complexity and Essential Complexity](https://en.wikipedia.org/wiki/No_Silver_Bullet)
+
+Exemplo:
+
+- [Lean Software Development: Eliminate Waste](https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste)
+
 ### Lei de Parkinson
 
 [Lei de Parkinson](https://en.wikipedia.org/wiki/Parkinson%27s_law)
@@ -199,6 +375,18 @@ Esse padrão continuou a se manter, e não se espera que pare até, no mínimo,
 
 A lei de Parkinson foi publicada por Cyril Northcote Parkinson num artigo na revista The Economist em 1955, sendo depois reimpresso com outros artigos no livro Parkinson's Law: The Pursuit of Progress [A lei de Parkinson: a busca do progresso]. Em seu contexto original, essa Lei foi baseada em estudos de burocracia. E pode ser pessimisticamente aplicado a desenvolvimento de software, a teoria diz que equipes serão ineficientes até os prazos finais, quando irão dar o máximo até o prazo final.
 
+### Efeito de Otimização Prematura
+
+[Premature Optimization on WikiWikiWeb](http://wiki.c2.com/?PrematureOptimization)
+
+> Otimização prematura é a raiz de todo o mal.
+>
+> [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en)
+
+No artigo de Donald Knuth, [Structured Programming With Go To Statements](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements), ele escreve: "Programadores perdem grandes quantidades de tempo pensando ou se preocupando com a velocidade de partes não críticas de seus programas, e essas tentativas de eficiência possuem um forte impacto negativo quando depuração e manutenção são consideradas. Nós devemos esquecer essas pequenas eficiências, cerca de 97% das vezes: **otimização prematura é a raiz de todo o mal.** No entanto, não devemos perder a oportunidade nesses 3% críticos".
+
+Contudo, _Otimização Prematura_ pode ser definida (em termos menos carregados) como otimizar antes de saber o que precisamos.
+
 ### Lei de Putt
 
 [Lei de Putt na wikipedia](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat)
@@ -209,130 +397,186 @@ A Lei de Putt é frequentemente seguida pelo Corolário de Putt:
 
 > Cada hierarquia técnica, no tempo, desenvolve uma inversão de competência.
 
-Estas declarações sugerem que devido a vários critérios de seleção e tendências na forma como grupos se organizam, haverá um número de pessoas qualificadas nos níveis de trabalho de organizações técnicas, e um número de pessoas em funções gerenciais que não estão cientes das complexidades e desafios do trabalho que estão gerenciando. Isso pode ser devido a fenômenos como  (#em-progresso)
+Estas declarações sugerem que devido a vários critérios de seleção e tendências na forma como grupos se organizam, haverá um número de pessoas qualificadas nos níveis de trabalho de organizações técnicas, e um número de pessoas em funções gerenciais que não estão cientes das complexidades e desafios do trabalho que estão gerenciando. Isso pode ser devido a fenômenos como o [Princípio de Peter](#o-princípio-de-peter) ou o [Princípio Dilbert](#o-princípio-dilbert).
+
+No entanto, deve-se enfatizar que leis como essa são vastas generalizações e podem ser aplicáveis a alguns tipos de organizações, mas não a outras.
 
 Veja também:
 
-- [O Principio de Peter](#em-progresso)
+- [Principio de Peter](#o-princípio-de-peter)
-- [Lei de Dilbert](#em-progresso).
+- [Princípio de Dilbert](#o-princípio-dilbert)
 
+### Lei de Reed
 
-### A lei da Conservação de Complexidade (Lei de Tesler)
+[Reed's Law on Wikipedia](https://en.wikipedia.org/wiki/Reed's_law)
+
+> A utilidade de grandes redes, particularmente redes sociais, escalam exponencialmente com o tamanho da própria rede.
+
+Essa lei é baseada na teoria dos grafos, onde a utilidade é escalonada com o número de possíveis subgrupos, que é mais rápido que o número de participantes ou o número de possíveis conexões pareadas. Odlyzko e outros argumentam que a Lei de Reed exagera a utilidade de um sistema por não levar em conta os limites da cognição humana sobre os efeitos da rede; veja [Número de Dunbar](#número-de-dunbar).
+
+Veja também:
+- [Lei de Metcalfe](##lei-de-metcalfe)
+- [Número de Dunbar](#número-de-dunbar)
+
+### A Lei da Conservação da Complexidade (Lei de Tesler)
 
 [A lei da Conservação de Complexidade na wikipedia](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity)
 
-Essa lei sugere que em todos sitemas sempre vai existir uma quantidade de complexidade que não pode ser reduzida.
+Essa lei sugere que em todos os sistemas sempre vai existir uma quantidade de complexidade que não pode ser reduzida.
 
 Alguma complexidade em um sistema é "inadvertida". É uma consequência da estrutura deficiente, erros ou apenas má modelagem de um problema a ser resolvido. A complexidade inadvertida pode ser reduzida (ou eliminada). No entanto, alguma complexidade é "intrínseca" como consequência da complexidade inerente ao problema a ser resolvido. Essa complexidade pode ser movida, mas não eliminada.
 
 Um elemento interessante para essa lei é a sugestão de que, mesmo simplificando todo o sistema, a complexidade intrínseca não é reduzida, ela é “movida para o usuário”, que deve se comportar de uma maneira mais complexa.
 
-### A lei das Abstrações gotejantes
+### A Lei das Abstrações Gotejantes
 
 [The Law of Leaky Abstractions on Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/)
 
 >Todas as abstrações não triviais, até certo ponto, são vazadas
 
-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.
+Essa lei afirma que abstrações, as quais são geralmente utilizadas na computação para simplificar um trabalho com sistemas complexos, em certas situações irão 'vazar' elementos do sistema subjacente, fazendo com que a abstração se comporte de maneira inesperada.
 
-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.
+Um exemplo disso pode ser carregar um arquivo e ler o seu conteúdo. As APIs do sistema de arquivo são abstrações do kernel de nível inferior, que são uma abstração dos processadores físicos relacionados à alteração de dados no disco rígido (ou na memória flash em SSD). Na maioria dos casos, a abstração de tratar um arquivo como um fluxo de dados binários funcionará. Contudo, para um disco rígido, a leitura sequencial dos dados será significantemente mais rápida que o acesso aleatório (devido ao aumento da sobrecarga de falhas na página), mas para um disco SSD, essa sobrecarga não estará presente. Os detalhes subjacentes precisarão ser entendidos para lidar com esse caso (por exemplo, os arquivos índices de uma base de dados são estruturados para reduzir a sobrecarga do acesso aleatório), a abstração 'vaza' detalhes de implementação os quais o desenvolvedor precisa estar ciente.
 
-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.
+O exemplo acima pode se tornar mais complexo quando _mais_ abstrações são introduzidas. O sistema operacional Linux permite que os arquivos sejam acessados por rede mas representados localmente como arquivos 'normais'. Essa abstração será 'vazada' se houverem falhas de rede. Se um desenvolvedor tratar esses arquivos como 'normais', sem considerar o fato de que eles podem estar sujeitos à latência e falhas na rede, as soluções serão incorretas.
 
-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.
+Veja também:
 
-See also:
+- [Lei de Hyrum](#lei-de-hyrum-lei-das-interfaces-implícitas)
 
-- [Hyrum's Law](#hyrums-law-the-law-of-implicit-interfaces)
+Exemplos do mundo real:
 
-Real-world examples:
+- [Photoshop Slow Startup](https://forums.adobe.com/thread/376152) - um problema que eu encontrei no passado. O Photoshop demorava para abrir, às vezes levando alguns minutos. Parecia que o problema era que, ao iniciar, o programa lia algumas informações sobre a impressora padrão. No entanto, se essa impressora fosse uma impressora de rede, isso demoraria tempo extremamente longo. A _abstração_ de uma impressora de rede ser mostrada ao sistema como uma impressora local causou um problema para usuários em situação de baixa conectividade.
 
-- [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.
+### A Lei da Trivialidade
-
-### 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.
+Essa lei sugere que grupos irão dar maior atenção para problemas triviais ou cosméticos, do que para os problemas sérios e substanciais.
 
-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.
+O exemplo fictício comum utilizado é o de um comitê aprovando planos para uma usina nuclear, que passam maior tempo discutindo a estrutura do bicicletário ao invés do design da própria usina que é muito mais importante. Pode ser difícil fornecer informações valiosas em discussões sobre tópicos muito grandes e complexos sem um alto grau de conhecimento ou preparação no assunto. No entanto, as pessoas querem ser vistas contribuindo com informações importantes. Daí uma tendência de concentrar muito tempo em pequenos detalhes, que podem ser facilmente explicados, mas necessariamente não são de importância particular.
 
-The fictional example above led to the usage of the term 'Bike Shedding' as an expression for wasting time on trivial details.
+O exemplo fictício acima levou ao uso do termo _'Bike Shedding'_ como uma expressão por gastar tempo em detalhes triviais.
 
-### The Unix Philosophy
+
+### A Filosofia Unix
 
 [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.
+A Filosofia Unix prega que componentes de um software devem ser pequenos, e focados em fazer muito bem uma coisa específica. Isso torna mais fácil a construção de sistemas compondo unidades pequenas, simples e bem definidas, em vez de usar programas grandes, complexos e multiuso.
 
-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.
+Práticas modernas como a 'Arquitetura de Microsserviços' podem ser pensadas como uma aplicação dessa lei, onde os serviços são pequenos, focados em uma tarefa específica, permitindo que um comportamento complexo seja composto de blocos de construção simples.
 
-### The Spotify Model
+### O Modelo Spotify
 
 [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.
+O Modelo Spotify é uma abordagem para a organização de equipes que foi popularizado pelo 'Spotify'. Neste modelo, times são organizados por funcionalidades, não por tecnologias.
 
-The Spotify Model also popularises the concepts of Tribes, Guilds, Chapters, which are other components of their organisation structure.
+O Modelo Spotify também popularizou o conceito de Tribos, Guildas, Capítulos, que são outros componentes de sua estrutura organizacional.
 
-### Wadler's Law
+### Lei de Wadler
 
 [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.
+> Em qualquer design de linguagem, o tempo total gasto discutindo a uma funcionalidade nessa lista é proporcional a dois elevados à potência de sua posição.
 >
-> 0. Semantics
+> 0. Semântica
-> 1. Syntax
+> 1. Sintaxe
-> 2. Lexical syntax
+> 2. Sintaxe léxica
-> 3. Lexical syntax of comments
+> 3. Sintaxe léxica de comentários
 >
-> (In short, for every hour spent on semantics, 8 hours will be spent on the syntax of comments).
+> (Em resumo, para cada hora gasta em semântica, 8 horas serão gastas na sintaxe de comentários)
 
-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.
+Semelhante à [Lei da Trivialidade](#a-lei-da-trivialidade), a Lei de Wadler afirma que quando projetamos uma linguagem, o tempo gasto em estruturas é desproporcionalmente maior do que a importância dessas funcionalidades.
 
-See also:
+Veja também:
 
 - [The Law of Triviality](#the-law-of-triviality)
 
-## Principles
+### Lei de Wheaton
 
-Principles are generally more likely to be guidelines relating to design.
+[The Link](http://www.wheatonslaw.com/)
 
-### The Pareto Principle (The 80/20 Rule)
+[The Official Day](https://dontbeadickday.com/)
+
+> Não seja um babaca
+>
+> _Wil Wheaton_
+
+Cunhada por Wil Wheaton (Star Trek: The Next Generation, The Big Bang Theory), esta lei simples, concisa e poderosa visa aumentar a harmonia e o respeito dentro de uma organização profissional. Ela pode ser aplicada ao conversar com colegas de trabalho, ao efetuar code reviews, contrariar outros pontos de vista, criticar, e, em linhas gerais, na maioria das interações que os humanos mantém entre si.
+
+## Princípios
+
+Os princípios são como diretrizes relacionadas à design.
+
+### O Princípio Dilbert
+
+[The Dilbert Principle on Wikipedia](https://en.wikipedia.org/wiki/Dilbert_principle)
+
+> Empresas tendem a promover sistematicamente funcionários incompetentes para a gerência para tirá-los do fluxo de trabalho.
+>
+> _Scott Adams_
+
+Um conceito de gerência desenvolvido por Scott Adams (criador da tirinha Dilbert), o Princípio de Dilbert é inspirado pelo [Princípio de Peter](#o-princípio-de-peter). Sob o Princípio de Dilbert, funcionários que nunca foram competentes são promovidos para a gerência, para limitar o estrago que eles podem causar. Adams explicou esse princípio pela primeira vez um artigo no Wall Street Journal, em 1995, e o expandiu para seu livro de negócios em 1996, o [The Dilbert Principle](#lista-de-leitura).
+
+Veja também:
+
+- [Princípio de Peter](#o-princípio-de-peter)
+- [Lei de Putt](#lei-de-putt)
+
+### O Princípio de Pareto (Regra do 80/20)
 
 [The Pareto Principle on Wikipedia](https://en.wikipedia.org/wiki/Pareto_principle)
 
-> Most things in life are not distributed evenly.
+> A maioria das coisas na vida não são distribuídas de maneira uniforme.
 
-The Pareto Principle suggests that in some cases, the majority of results come from a minority of inputs:
+O Princípio de Pareto sugere que em alguns casos, a maioria dos resultados vem de uma minoria de insumos:
 
-- 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)
+- 80% de um certo pedaço de software pode ser escrito em 20% do tempo total alocado (inversamente, os 20% mais difíceis do código levam 80% do tempo)
-- 20% of the effort produces 80% of the result
+- 20% do esforço produz 80% do resultado
-- 20% of the work creates 80% of the revenue
+- 20% do trabalho cria 80% da receita
-- 20% of the bugs cause 80% of the crashes
+- 20% dos bugs causam 80% das quebras
-- 20% of the features cause 80% of the usage
+- 20% das funcionalidades causam 80% da utilização
 
-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).
+Nos anos 40 o engenheiro americano-romeno Dr. Joseph Juran, reconhecido como pai do controle de qualidade, [começou a aplicar o Princípio de Pareto a questões de qualidade](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.
+Este princípio é também conhecido como: A Regra do 80/20, A Lei dos Poucos Vitais e O Princípio de Escassez do Fator.
 
-Real-world examples:
+Exemplos do mundo real:
 
-- 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)).
+- Em 2002 a Microsoft reportou que corrigindo 20% dos erros mais reportados, 80% dos erros e quebras relacionadas no Windows e no Office foram eliminados ([Referência](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)).
 
-### The Robustness Principle (Postel's Law)
+### O Princípio de Peter
+
+[The Peter Principle on Wikipedia](https://en.wikipedia.org/wiki/Peter_principle)
+
+> Pessoas em uma hierarquia tentem a subir ao seu "nível de incompetência".
+>
+> _Laurence J. Peter_
+
+Um conceito de gerenciamento desenvolvido por Laurence J. Peter, o Princípio de Peter observa que as pessoas que são boas em seu emprego são promovidas até um nível onde elas não são mais bem-sucedidas (o "nível de incompetência"). Neste ponto, à medida em que são mais seniores, é menos provável que elas sejam removidas da organização (a não ser que elas performem de maneira horrível) e irão continuar a permanecer em uma função na qual possuem poucas habilidades intrínsecas, pois as habilidades originais que as fizeram bem-sucedidas não são necessariamente as mesmas que o novo cargo exige.
+
+Isso é de interesse particular para engenheiros - que inicialmente começam em funções técnicas mas tem uma carreira que leva ao _gerenciamento_ de outros engenheiros - o que requer um conjunto de habilidades fundamentalmente diferente.
+
+Veja também:
+
+- [The Dilbert Principle](#the-dilbert-principle)
+- [Putt's Law](#putts-law)
+
+### O Princípio da Robustez (Lei de Postel)
 
 [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.
+> Seja conservador naquilo que você faz, seja liberal naquilo que você aceita dos outros.
 
-Often applied in server application development, this principle states that what you send to others should be as minimal and conformant as possible, but you should be aim to allow non-conformant input if it can be processed.
+Geralmente aplicado no desenvolvimento de aplicativos para servidor, esse princípio afirma que o que você envia para outras pessoas deve ser o mínimo compatível possível, mas que você deve ter como objetivo permitir entradas fora de conformidade, se puderem ser processadas.
 
-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.
+O objetivo desse princípio é construir sistemas que são robustos, pois eles conseguem lidar com dados mal formatados se a intenção ainda puder ser entendida. No entanto, há potenciais implicações de segurança na aceitação de entradas mal formatadas, principalmente se o processamento dessas entradas não for bem testado.
 
 ### SOLID
 
-This is an acronym, which refers to:
+É um acrônimo para:
 
 * S: [The Single Responsibility Principle](#the-single-responsibility-principle)
 * O: [The Open/Closed Principle](#the-openclosed-principle)
@@ -340,140 +584,216 @@ This is an acronym, which refers to:
 * I: [The Interface Segregation Principle](#the-interface-segregation-principle)
 * D: [The Dependency Inversion Principle](#the-dependency-inversion-principle)
 
-These are key principles in [Object-Oriented Programming](#todo). Design principles such as these should be able to aid developers build more maintainable systems.
+Esses são os princípios-chave da [Programação Orientada a Objetos](#todo). Os princípios de design como esses devem ajudar os desenvolvedores a criarem sistemas mais sustentáveis.
 
-### The Single Responsibility Principle
+### O Princípio da Responsabilidade Única
 
 [The Single Responsibility Principle on Wikipedia](https://en.wikipedia.org/wiki/Single_responsibility_principle)
 
-> Every module or class should have a single responsibility only.
+> Cada módulo ou classe deve possuir apenas uma única responsabilidade.
 
-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.
+O primeiro dos princípios '[SOLID](#solid)'. Esse princípio sugere que módulos ou classes devem fazer apenas uma única coisa. Em termos mais práticos, isso significa que uma mudança simples a uma funcionalidade de um programa deve exigir uma mudança em apenas um componente. Por exemplo, mudar como uma senha é validada por complexidade deve exigir uma mudança em apenas uma parte do programa.
 
-Theoretically, this should make the code more robust, and easier to change. Knowing that a component which is 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.
+Teoricamente, isso deve tornar o código mais robusto, e fácil de ser mudado. Sabendo que um componente que está sendo alterado possui apenas uma responsabilidade significa que o _teste_ deverá ser mais fácil. Usando o exemplo anterior, trocar a complexidade do componente de senha deve afetar apenas as funcionalidades que são relacionadas com a complexidade de senha. Pode ser muito mais difícil argumentar sobre o impacto de uma alteração em um componente que tem muitas responsabilidades.
 
-See also:
+Veja também:
 
 - [Object-Oriented Programming](#todo)
 - [SOLID](#solid)
 
-### The Open/Closed Principle
+### O Princípio do Aberto/Fechado
 
 [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.
+> Entidades devem estar aberta para extensão e fechadas para modificação
 
-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.
+O segundo princípio do '[SOLID](#solid)'. Esse princípio afirma que entidades (que podem ser classes, módulos, funções e afins) poderão ter seu comportamento _estendido_, mas que o comportamento já existente não poderá ser alterado.
 
-As a hypothetical example, imagine a module which is able to turn a Markdown document into HTML. If the module could be extended to handle a newly proposed markdown feature, without modifying the module internals, then it would be open for extension. If the module could _not_ be modified by a consumer so that how existing Markdown features are handled, then it would be _closed_ for modification.
+Em um exemplo hipotético, imagine um módulo que converte um documento Markdown para HTML. Se o módulo pode ser estendido para aceitar uma nova funcionalidade do markdown, sem modificar a parte interna desse módulo, quer dizer que ele está aberto para extensões. Se o módulo _não_ pode ser modificado por um consumidor, de modo que as funcionalidades existentes do markdown sejam tratadas, então ele estará _fechado_ para modificações.
 
-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.
+Esse princípio tem uma relevância particular na orientação a objetos, onde nós projetamos objetos para serem facilmente estendidos, mas evitamos projetar objetos onde o comportamento existente pode ser alterado de maneiras inesperadas.
 
-See also:
+Veja também:
 
 - [Object-Oriented Programming](#todo)
 - [SOLID](#solid)
 
-### The Liskov Substitution Principle
+### O Princípio da Substituição de Liskov
 
 [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.
+> Deve ser possível trocar um tipo por um subtipo, sem o sistema apresentar quebras.
 
-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.
+O terceiro princípio '[SOLID](#solid)'. O princípio afirma que se um componente confia em um tipo, então ele deverá estar apto para utilizar subtipos daquele tipo, sem que o sistema falhe ou que ele conheça os detalhes daquele subtipo.
 
-As an example, imagine we have a method which reads an XML document from a structure which represents a file. If the method uses a base type 'file', then anything which derives from 'file' should be able to be used in the function. If 'file' supports seeking in reverse, and the XML parser uses that function, but the derived type 'network file' fails when reverse seeking is attempted, then the 'network file' would be violating the principle.
+Como um exemplo, imagine que temos um método que lê um documento XML de uma estrutura que representa um arquivo. Se o método utiliza a base de um tipo 'arquivo', então qualquer coisa que seja derivada de 'arquivo' poderá ser utilizada na função. Se 'arquivo' suporta busca recursiva, e o interpretador de XML utiliza essa função, mas o tipo derivado 'arquivo de rede' falha quando tenta uma busca recursiva, então o tipo 'arquivo de rede' estaria violando o princípio.
 
-This principle has particular relevance for object-oriented programming, where type hierarchies must be modeled carefully to avoid confusing users of a system.
+Esse princípio tem uma relevância particular na orientação a objetos, onde as hierarquias de tipos precisam ser modeladas com cautela para evitar confusão entre usuários do sistema.
 
-See also:
+Veja também:
 
 - [Object-Oriented Programming](#todo)
 - [SOLID](#solid)
 
-### The Interface Segregation Principle
+### O Princípio da Segregação de Interface
 
 [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.
+> Nenhum cliente deverá ser forçado a depender de métodos que ele não utilize.
 
-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.
+O quarto princípio do '[SOLID](#solid)'. Esse princípio afirma que os consumidores de um componente não devem depender de funções daquele componente, as quais eles atualmente não usem.
 
-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.
+Como um exemplo, imagine que um método lê um documento XML de uma estrutura que representa um arquivo. O método apenas precisa ler os bytes, ir para frente ou para trás no arquivo. Se esse método precisar ser atualizado porque um recurso não relacionado da estrutura do arquivo é alterado (como uma atualização no modelo de permissões utilizado para representar a segurança do arquivo), o princípio foi invalidado.
 
-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.
+Esse princípio tem uma relevância particular na orientação a objetos, onde interfaces, hierarquias e tipos abstratos são utilizados para [minimizar o acoplamento](#todo) entre componentes diferentes. [Duck typing]() é uma metodologia que impõe esse princípio, eliminando interfaces explícitas.
 
-See also:
+Veja também:
 
 - [Object-Oriented Programming](#todo)
 - [SOLID](#solid)
 - [Duck Typing](#todo)
 - [Decoupling](#todo)
 
-### The Dependency Inversion Principle
+### O Princípio da Inversão de Dependência
 
 [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.
+> Módulos de alto nível não devem ser dependentes de implementações de baixo nível.
 
-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.
+O quinto conceito do '[SOLID](#solid)'. Esse princípio afirma que componentes
 
-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.
+Como um exemplo, imagine que temos um programa que lê os metadados de um website. Nós devemos assumir que o componente principal precisa conhecer um componente que irá baixar a página, depois um outro componente que irá ler os metadados. Se fôssemos levar a inversão de dependências em conta, o componente principal deveria depender apenas de um componente abstrato que pode buscar pelos bytes, e depois outro componente abstrato que irá ler os metadados de um fluxo de bytes. O componente principal não sabe nada sobre 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).
+Esse princípio é complexo, pois pode "inverter" as dependências esperadas de um sistema (daí o nome). Na prática, isso também significa que um componente de orquestração separado deve garantir que as implementações corretas dos tipos abstratos sejam usadas (por exemplo, no caso anterior, _algo_ ainda deve fornecer ao componente de leitura dos de metadados um downloader de arquivos HTTP e um leitor de metatags HTML). Isso toca em padrões como [Inversão de controle](#todo) e [Injeção de dependência](#todo).
 
-See also:
+Veja também:
 
 - [Object-Oriented Programming](#todo)
 - [SOLID](#solid)
 - [Inversion of Control](#todo)
 - [Dependency Injection](#todo)
 
-### The DRY Principle
+### O Princípio DRY
 
 [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.
+> Cada pedaço de código deve possuir uma representação única, inequívoca e autoritária dentro de um sistema.
 
-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 Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+DRY é um acrônimo para _**D**on't **R**epeat **Y**ourself_ (Não repita você mesmo). Esse princípio ajuda os desenvolvedores a reduzir a repetição de código e manter a informação em um único lugar. Foi citado em 1999 por Andrew Hunt e Dave Thomas no livro [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).
+> O oposto de DRY seria WET (Write Everything Twice or We Enjoy Typing) - (Escreva tudo duas vezes ou Nós gostamos de digitar).
 
-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.
+Na prática, se você tem o mesmo pedaço de informação em dois (ou mais) lugares diferentes, você pode utilizar o DRY para centralizá-los em um único lugar, e reutilizar a informação onde necessário.
 
-See also:
+Veja também:
 
-- [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+- [The Pragmatic Programmer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+
+### O Princípio KISS
+
+[KISS on Wikipedia](https://en.wikipedia.org/wiki/KISS_principle)
+
+> Mantenha simples, idiota
+
+KISS é um acrônimo para _**K**eep **i**t **s**imple, **s**tupid_. O princípio afirma que a maioria dos sistemas trabalham melhor se eles são mantidos simples ao invés de complicados. Portanto, simplicidade deve ser um objetivo no design, e complexidades desnecessárias devem ser evitadas. Originada na Marinha Americana em 1960, a frase foi associada com o engenheiro de aeronaves Kelly Johnson.
+
+O princípio é melhor exemplificado pela história de Johnson entregando a uma equipe de engenheiros de projeto algumas ferramentas, com o desafio de que as aeronaves a jato que estavam projetando deveriam ser reparadas por um mecânico comum em campo sob condições de combate apenas com essas ferramentas. Portanto, o "estúpido" refere-se à relação entre a maneira como as coisas quebram e a sofisticação das ferramentas disponíveis para repará-las, e não as capacidades dos próprios engenheiros.
+
+Veja também:
+
+- [Lei de Gall](#lei-de-gall)
 
 ### YAGNI
 
 [YAGNI on Wikipedia](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it)
 
-This is an acronym for _**Y**ou **A**ren't **G**onna **N**eed **I**t_.
+É um acrônimo para _**Y**ou **A**ren't **G**onna **N**eed **I**t_ - Você não vai precisar disto.
 
-> Always implement things when you actually need them, never when you just foresee that you need them.
+> Sempre implemente as coisas quando você de fato precisar delas, nunca quando você prevê que precisará delas.
 >
-> ([Ron Jeffries](https://twitter.com/RonJeffries)) (XP co-founder and author of the book "Extreme Programming Installed")
+> ([Ron Jeffries](https://twitter.com/RonJeffries)) (XP co-founder e autor do livro "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.
+Este princípio da _Extreme Programming_ (XP) sugere que os desenvolvedores apenas devem implementar funcionalidades quando elas forem necessárias, e evitar tentativas de prever o futuro e implementar uma funcionalidade que talvez seja necessária.
 
-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.
+Aderir a esse princípio deve reduzir a quantidade de código não utilizado em um projeto, e evitar tempo e esforço sendo desperdiçados em funcionalidades que não agregam valor.
 
-See also:
+Veja também:
 
-- [Reading List: Extreme Programming Installed](#reading-list)
+- [Reading List: Extreme Programming Installed](#lista-de-leitura)
+
+### As Falácias da Computação Distribuída
+
+[The Fallacies of Distributed Computing on Wikipedia](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing)
+
+Também conhecidas como as _Falácias da Computação em rede_, as Falácias são uma lista de conjecturas (ou crenças) sobre a computação distribuídas, que podem levar a falhas no desenvolvimento de software. As suposições são:
+
+- A rede é confiável
+- A latência é zero
+- A largura de banda é infinita
+- A rede é segura
+- A topologia não muda
+- Existe apenas um administrador
+- Custo de transporte é zero
+- A rede é homogênea
+
+Os primeiro quatro itens foram listados por [Bill Joy](https://en.wikipedia.org/wiki/Bill_Joy) e [Tom Lyon](https://twitter.com/aka_pugs) por volta de 1991, e foram classificados por [James Gosling](https://en.wikipedia.org/wiki/James_Gosling) como as "Falácias da Computação de rede". [L. Peter Deutsch](https://en.wikipedia.org/wiki/L._Peter_Deutsch) adicionou os itens 5, 6 e 7. No final dos anos 90, Gosling adicionou o item 8.
+
+O grupo foi inspirado pela situação que corria na época dentro da [Sun Microsystems](https://en.wikipedia.org/wiki/Sun_Microsystems).
+
+Essas falácias devem ser consideradas com cuidado ao projetar um código que seja resiliente; supondo que qualquer uma dessas falácias possa levar a uma lógica defeituosa que falha em lidar com as realidades e complexidades dos sistemas distribuídos
+
+Veja também:
+
+- [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)
+- [Deutsch's Fallacies, 10 Years After](http://java.sys-con.com/node/38665)
+
+## Lista de leitura
 
 
-## Lista de Livros
+Se você achou esses conceitos interessantes, você provavelmente vai gostar dos seguintes livros.
 
-If you have found these concepts interesting, you may enjoy the following books.
+- [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Cobre os principais princípios do Extreme Programming.
+- [The Mythical Man Month - Frederick P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - Um volume clássico na engenharia de software. A [Lei de Brook](#brooks-law) é o tema central desse livro.
+- [Gödel, Escher, Bach: An Eternal Golden Braid - Douglas R. Hofstadter.](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - Esse livre é difícil de classificar. A [Lei de Hofstadter](#hofstadters-law) é desse livro.
+- [The Dilbert Principle - Scott Adams](https://www.goodreads.com/book/show/85574.The_Dilbert_Principle) - Um olhar cômico sobre a América corporativa, do autor que criou o [Princípio Dilbert](#the-dilbert-principle).
+- [The Peter Principle - Lawrence J. Peter](https://www.goodreads.com/book/show/890728.The_Peter_Principle) - Outro olhar cômico sobre os desafios de grandes organizações e sobre a gestão de pessoas, a fonte do [Princípio de Peter](#the-peter-principle).
 
-- [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Covers the core principles of Extreme Programming.
+## Traduções
-- [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.
-- [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.
 
-## Em Progresso
+Graças a contribuidores maravilhosos, Hacker Laws está disponível em vários idiomas. Por favor, considere em patrocinar os moderadores!
 
-Hi! If you land here, you've clicked on a link to a topic I've not written up yet, sorry about this - this is work in progress!
+| Idioma   | Moderador | Status |
+|----------|-----------|--------|
+| [🇮🇩 Bahasa Indonesia / Indonesian](./translations/pt-BR.md) | [arywidiantara](https://github.com/arywidiantara) | [![gitlocalized ](https://gitlocalize.com/repo/2513/id/badge.svg)](https://gitlocalize.com/repo/2513/id?utm_source=badge) |
+| [🇧🇷 Português Brasileiro / Brazilian Portuguese](./translations/pt-BR.md) | [Eugênio Moreira](https://github.com/eugenioamn), [Leonardo Costa](https://github.com/leofc97) | [![gitlocalized ](https://gitlocalize.com/repo/2513/pt-BR/badge.svg)](https://gitlocalize.com/repo/2513/pt-BR?utm_source=badge) |
+| [🇨🇳 中文 / Chinese](https://github.com/nusr/hacker-laws-zh) | [Steve Xu](https://github.com/nusr) | Parcialmente completa |
+| [🇩🇪 Deutsch / German](./translations/de.md) | [Vikto](https://github.com/viktodergunov) | [![gitlocalized ](https://gitlocalize.com/repo/2513/de/badge.svg)](https://gitlocalize.com/repo/2513/de?utm_source=badge) |
+| [🇫🇷 Français / French](./translations/fr.md) | [Kevin Bockelandt](https://github.com/KevinBockelandt) | [![gitlocalized ](https://gitlocalize.com/repo/2513/fr/badge.svg)](https://gitlocalize.com/repo/2513/fr?utm_source=badge) |
+| [🇬🇷 ελληνικά / Greek](./translations/el.md) | [Panagiotis Gourgaris](https://github.com/0gap) | [![gitlocalized ](https://gitlocalize.com/repo/2513/el/badge.svg)](https://gitlocalize.com/repo/2513/el?utm_source=badge) |
+| [🇮🇹 Italiano / Italian](https://github.com/csparpa/hacker-laws-it) | [Claudio Sparpaglione](https://github.com/csparpa) | Parcialmente completa |
+| [🇯🇵 JP 日本語 / Japanese](./translations/jp.md) | [Fumikazu Fujiwara](https://github.com/freddiefujiwara)| [![gitlocalized ](https://gitlocalize.com/repo/2513/ja/badge.svg)](https://gitlocalize.com/repo/2513/ja?utm_source=badge) |
+| [🇰🇷 한국어 / Korean](https://github.com/codeanddonuts/hacker-laws-kr) | [Doughnut](https://github.com/codeanddonuts) | Parcialmente completa |
+| [🇱🇻 Latviešu Valoda / Latvian](./translations/lv.md) | [Arturs Jansons](https://github.com/iegik) | [![gitlocalized ](https://gitlocalize.com/repo/2513/lv/badge.svg)](https://gitlocalize.com/repo/2513/lv?utm_source=badge) |
+| [🇷🇺 Русская версия / Russian](https://github.com/solarrust/hacker-laws) | [Alena Batitskaya](https://github.com/solarrust) | Parcialmente completa |
+| [🇪🇸 Castellano / Spanish](./translations/es-ES.md) | [Manuel Rubio](https://github.com/manuel-rubio) ([Sponsor](https://github.com/sponsors/manuel-rubio)) | Parcialmente completa |
+| [🇹🇷 Türkçe / Turkish](https://github.com/umutphp/hacker-laws-tr) | [Umut Işık](https://github.com/umutphp) | [![gitlocalized ](https://gitlocalize.com/repo/2513/tr/badge.svg)](https://gitlocalize.com/repo/2513/tr?utm_source=badge) |
 
-Feel free to [Raise an Issue](https://github.com/dwmkerr/hacker-laws/issues) requesting more details, or [Open a Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) to submit your proposed definition of the topic. 
+Se você quer atualizar uma tradução, [abra uma pull request](https://github.com/dwmkerr/hacker-laws/compare). Se você quer adicionar um novo idioma, crie uma conta no [GitLocalize](https://gitlocalize.com/), depois abra uma issue pedindo ao administrador o idioma eu irei adicionar você no projeto! Seria muito útil se você conseguir abrir uma pull request que atualiza a tabela acima, adicionando link ao topo do arquivo.
+
+## Projetos relacionados
+
+- [Tip of the Day](https://tips.darekkay.com/html/hacker-laws-en.html) - Receba diariamente uma lei ou princípio hacker.
+- [Hacker Laws CLI](https://github.com/umutphp/hacker-laws-cli) - Liste e visualize as leis de maneira aleatória no seu terminal!
+
+## Contribuindo
+
+Por favor, contribua! [Abra uma issue](https://github.com/dwmkerr/hacker-laws/issues/new) se você deseja ver aqui algum conteúdo novo, sugerir uma alteração/correção, ou então [abra uma pull request](https://github.com/dwmkerr/hacker-laws/compare) e proponha suas próprias modificações.
+
+Certifique-se de ler as [Diretrizes de Contribuição](../.github/contributing.md) para saber sobre os padrões de texto, estilo etc. Esteja ciente do [Código de Conduta](../.github/CODE_OF_CONDUCT.md) ao participar de discussões sobre o projeto.
+
+## Em construção
+
+Olá! Se você parou aqui, clicou em um link para um tópico que não foi escrito ainda. Desculpe por isso, este trabalho está em andamento!
+
+Sinta-se livre para [abrir uma issue](https://github.com/dwmkerr/hacker-laws/issues) solicitando mais detalhes, ou [abra uma pull request](https://github.com/dwmkerr/hacker-laws/compare) para submeter suas modificações.

translations/tr.md

@@ -2,13 +2,7 @@
 
 Programcıların faydalı bulacağı yasalar, teoriler, prensipler ve desenler.
 
-- 🇨🇳 [中文 / Çince İçin](https://github.com/nusr/hacker-laws-zh) - Teşekkürler [Steve Xu](https://github.com/nusr)!
+[Çeviriler](#%C3%A7eviriler): [🇮🇩](./translations/pt-BR.md) [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇩🇪](./translations/de.md) [🇫🇷](./translations/fr.md) [🇬🇷](./translations/el.md) [🇮🇹](https://github.com/csparpa/hacker-laws-it) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](https://github.com/umutphp/hacker-laws-tr) [🇯🇵](./translations/jp.md)
-- 🇮🇹 [Italyanca için](https://github.com/csparpa/hacker-laws-it) - Teşekkürler [Claudio Sparpaglione](https://github.com/csparpa)!
-- 🇰🇷 [한국어 / Korece İçin](https://github.com/codeanddonuts/hacker-laws-kr) - Teşekkürler [Doughnut](https://github.com/codeanddonuts)!
-- 🇷🇺 [Русская версия / Rusça İçin](https://github.com/solarrust/hacker-laws) - Teşekkürler [Alena Batitskaya](https://github.com/solarrust)!
-- 🇹🇷 [Türkçe / Turkçe İçin](https://github.com/umutphp/hacker-laws-tr) - Teşekkürler [Umut Işık](https://github.com/umutphp)
-- 🇧🇷 [Brasileiro / Brezilyaca İçin](./translations/pt-BR.md) - Teşekkürler [Leonardo Costa](https://github.com/LeoFC97)
-- 🇪🇸 [Castellano / İspanyolca İçin](./translations/es-ES.md) - Teşekkürler [Manuel Rubio](https://github.com/manuel-rubio)
 
 Bu projeyi beğendiniz mi? Lütfen [sponsor olmayı](https://github.com/sponsors/dwmkerr) düşünün!
 
@@ -16,29 +10,36 @@ Bu projeyi beğendiniz mi? Lütfen [sponsor olmayı](https://github.com/sponsors
 
 <!-- vim-markdown-toc GFM -->
 
-- [Giriş](#introduction)
+- [Giriş](#giri%C5%9F)
-- [Yasalar](#laws)
+- [Yasalar](#yasalar)
-    - [Amdahl Yasası](#amdahls-law)
+    - [90–9–1 Prensibi (1% Kuralı)](#9091-prensibi-1-kural%C4%B1)
-    - [Kırık Camlar Teorisi](#k%C4%B1r%C4%B1k-camlar-teorisi)
+    - [Amdahl Yasası](#amdahl-yasas%C4%B1)
+    - [Kırık Camlar Teorisi](#the-broken-windows-theory)
     - [Brooks Yasası](#brooks-law)
+    - [CAP Teorisi (Brewer Teorisi)](#cap-teroisi-brewer-teorisi)
     - [Conway Yasası](#conways-law)
     - [Cunningham Yasası](#cunninghams-law)
     - [Dunbar Sayısı](#dunbars-number)
+    - [Fitt Yasası](#fitt-yasas%C4%B1)
     - [Gall Yasası](#galls-law)
     - [Goodhart Yasası](#goodharts-law)
     - [Hanlon'un Usturası](#hanlons-razor)
+    - [Hick Yasası (Hick-Hyman Yasası)](#hick-yasas%C4%B1-hick-hyman-yasas%C4%B1)
     - [Hofstadter Yasası](#hofstadters-law)
     - [Hutber Yasası](#hutbers-law)
     - [Hype Döngüsü ve Amara Yasası](#the-hype-cycle--amaras-law)
     - [Hyrum Yasası (Arabirimlerin Örtülü Hukuku)](#hyrums-law-the-law-of-implicit-interfaces)
+    - [Kernighan Yasası](#kernighans-law)
     - [Metcalfe Yasası](#metcalfes-law)
     - [Moore Yasası](#moores-law)
     - [Murphy Yasası / Sod  Yasası](#murphys-law--sods-law)
+    - [Occam'ın Usturası](#occams-razor)
     - [Parkinson Yasası](#parkinsons-law)
     - [Olgunlaşmamış Optimizasyon Etkisi](#premature-optimization-effect)
     - [Putt Yasası](#putts-law)
     - [Reed Yasası](#reeds-law)
     - [Karmaşıklığın Korunması Yasası (Tesler Yasası)](#the-law-of-conservation-of-complexity-teslers-law)
+    - [Demeter Yasası](#demeter-yasas%C4%B1)
     - [Sızdıran Soyutlamalar Yasası](#the-law-of-leaky-abstractions)
     - [Önemsizlik Yasası](#the-law-of-triviality)
     - [Unix Felsefesi](#the-unix-philosophy)
@@ -46,6 +47,7 @@ Bu projeyi beğendiniz mi? Lütfen [sponsor olmayı](https://github.com/sponsors
     - [Wadler Yasası](#wadlers-law)
     - [Wheaton Yasası](#wheatons-law)
 - [Prensipler](#principles)
+    - [Ölü Deniz Etkisi](#%C3%B6l%C3%BC-deniz-etkisi)
     - [Dilbert Prensibi](#the-dilbert-principle)
     - [Pareto Prensibi (80/20 Kuralı)](#the-pareto-principle-the-8020-rule)
     - [Peter Prensibi](#the-peter-principle)
@@ -59,9 +61,11 @@ Bu projeyi beğendiniz mi? Lütfen [sponsor olmayı](https://github.com/sponsors
     - [DRY Prensibi](#the-dry-principle)
     - [KISS prensibi](#the-kiss-principle)
     - [YAGNI](#yagni)
-    - [Dağıtık Sistemlerin Yanılgıları](#the-fallacies-of-distributed-computing)
+    - [Dağıtık Sistemlerin Yanılgıları](#da%C4%9F%C4%B1t%C4%B1k-sistemlerin-yan%C4%B1lg%C4%B1lar%C4%B1)
 - [Ek Kaynaklar](#reading-list)
-- [Katkıda Bulunmak İçin](#katk%C4%B1)
+- [Çeviriler](#translations)
+- [Katkıda Bulunmak İçin](#related-projects)
+- [Katkıda Bulunmak İçin](#contributing)
 - [TODO](#todo)
 
 <!-- vim-markdown-toc -->
@@ -76,6 +80,20 @@ Bu projeyi beğendiniz mi? Lütfen [sponsor olmayı](https://github.com/sponsors
 
 Tek tek başlayalım!
 
+### 90–9–1 Prensibi (1% Kuralı)
+
+[Wikipedia'da 1% Kuralı](https://en.wikipedia.org/wiki/1%25_rule_(Internet_culture))
+
+90-9-1 prensibi der ki, bir internet topluluğunda (örneğin bir wiki) üyelerin %90'ı sadece içeriği okur, %9'u içeriği düzenleme ya da düzeltme yapar ve %1'i ise yeni içerik ekler.
+
+Gerçek dünyadan örnekler:
+
+- Dört dijital sağlık sosyal ağlarına ilişkin 2014 yılında yapılan bir araştırma, topluluğun %1'inin gönderilerin %73'ünü oluşturduğunu, %9'unun ortalama %25'ini ve geri kalan %90'ının da ortalama %2'sini oluşturduğunu buldu ([Referans](https://www.jmir.org/2014/2/e33/)).
+
+Ek kaynaklar:
+
+- [Pareto prensibi](#pareto-prensibi-8020-kural%C4%B1)
+
 ### Amdahl Yasası
 
 [Wikipedia Amdahl Yasası](https://en.wikipedia.org/wiki/Amdahl%27s_law)
@@ -86,7 +104,7 @@ En güzel şu örnekle anlatılabilir. Bir programın iki bölümden oluştuğun
 
 Aşağıdaki diyagram bazı olası hız geliştirmelerine örnekler içeriyor:
 
-<img width="480px" alt="Diagram: Amdahl's Law" src="../images/amdahls_law.png">
+<img width="480px" alt="Diagram: Amdahl's Law" src="../../../../images/amdahls_law.png">
 
 *(Diyagramın kaynağı: Daniels220 tarafından İngilizce Wikipedia'da, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)*
 
@@ -109,7 +127,7 @@ Bu teori, yazılım geliştirmeye şu şekilde uygulanabilir; düşük kalite ko
 
 Ek kaynaklar:
 
-- [Teknik Borç](#yapmak)
+- [Teknik Borç](#TODO)
 
 Örnekler:
 
@@ -134,6 +152,30 @@ Ek kaynaklar:
 - [Death March](#todo)
 - [Reading List: The Mythical Man Month](#reading-list)
 
+### CAP Teorisi (Brewer Teorisi)
+
+CAP Teoremi (Eric Brewer tarafından tanımlanmıştır) dağıtılmış bir veri deposu için aşağıdaki üç garantiden sadece ikisinin (en fazla) sağlanabileceğini belirtmektedir:
+
+- Tutarlılık: verileri okurken, her istek verinin *en son* halini alır veya bir hata döndürülür
+- Erişilebilirlik: veri okurken, her istek verinin *en son*hali olduğunu garanti etmeden *hata içermeyen bir yanıt* alır
+- Parçalara Ayrılma Toleransı: Düğümler arasında belli bir sayıda ağ isteği başarısız olduğunda, sistem beklendiği gibi çalışmaya devam eder
+
+Tartışmanın özü şöyledir. Bir ağ paylaşımının olmayacağını garanti etmek imkansızdır (bkz. [Dağıtık Sistemlerin Yanılgıları ](#da%C4%9F%C4%B1t%C4%B1k-sistemlerin-yan%C4%B1lg%C4%B1lar%C4%B1)). Bu nedenle bir paylaşımlı yapı söz konusu olduğunda, işlemi iptal edebilir (tutarlılığı artırabilir ve kullanılabilirliği azaltabiliriz) veya devam edebiliriz (kullanılabilirliği artırabilir, tutarlılığı azaltabilir).
+
+Teorinin ismi, garanti edilmeye çalışılan kavramların ilk harflerinden (Consistency, Availability, Partition Tolerance) oluşturulmuştur. Bunun [*ACID*](#TODO) ile alakalı *olmayan* farklı bir tanımı olduğunu bilmenin çok önemli olduğunu unutmayın. Daha güncel olarak, ağın paylaşımlı *olmadığı* yapılarda (sistem beklendiği çalışmaya devam ederken) gecikmeye ve tutarlılığa bazı kısıtlamalar getiren [PACELC](#TODO) teoremi geliştirilmiştir.
+
+Çoğu modern veritabanı platformu, veritabanı kullanıcılarına yüksek düzeyde kullanılabilirlik ('kirli okuma' içerebilir) veya yüksek düzeyde tutarlık (örneğin 'yeterli çoğunlukla onaylanmış yazma') arasında seçim yapma seçeneği sunarak bu teoremi örtük olarak kabul eder.
+
+Gerçek dünyadan örnekler:
+
+- [Google Cloud Spanner ve CAP Teorisi](https://cloud.google.com/blog/products/gcp/inside-cloud-spanner-and-the-cap-theorem) - İlk olarak CAP garantilerinin *hepsine* sahip gibi görünen, ancak kaputun altında bir CP sistemi olan Cloud Spanner'ın nasıl çalıştığının ayrıntıları anlatılıyor.
+
+Ek kaynaklar:
+
+- [ACID](#TODO)
+- [Dağıtık Sistemlerin Yanılgıları](#the-fallacies-of-distributed-computing)
+- [PACELC](#TODO)
+
 ### Conway Yasası
 
 [Wikipedia'da Conway Yasası](https://en.wikipedia.org/wiki/Conway%27s_law)
@@ -168,14 +210,30 @@ Ek kaynaklar:
 
 - [Conway Yasası](#conways-law)
 
+### Fitt Yasası
+
+[Wikipedia'da Fitt Yasası](https://en.wikipedia.org/wiki/Fitts%27s_law)
+
+Fitts yasası, bir hedef alana gitmek için gereken sürenin hesaplanmasında, hedefe olan mesafenin hedefin genişliğine bölünmesinin bir işlevi olduğunu öngörür.
+
+<img width="300px" alt="The Hype Cycle" src="./images/Fitts_Law.svg">
+
+*(Diagramın Kaynağı: By Foobar628 at English Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/Fitts%27s_law#/media/File:Fitts_Law.svg)*
+
+Bu yasanın sonuçları, UX veya UI tasarlanırken etkileşimli öğelerin mümkün olduğunca büyük olması ve kullanıcıların dikkat alanı ile etkileşimli öğe arasındaki mesafenin mümkün olduğunca küçük olması gerektiğini ortaya çıkarır. Bunun tasarım üzerinde sonuçları vardır, örneğin birbirleriyle yakın kullanılan işlevlerin gruplanması gibi.
+
+Ayrıca, ekranın köşeleri için temel kullanıcı arayüzü öğelerinin yerleştirilebileceği 'sihirli köşeler' (bir kullanıcının farelerini kolayca vurabileceği ya da süpürebileceği) kavramını resmileştiriyor. Windows Başlat düğmesi sihirli bir köşede, seçmeyi kolaylaştırıyor ve ilginç bir kontrast olarak, MacOS'un 'pencereyi kapat' düğmesi sihirli bir köşede *değil*, yanlışlıkla tıklanmayı zorlaştırıyor.
+
+Ek kaynaklar:
+
+- [İnsan motor sisteminin hareket genliğini kontrol etme veri kapasitesi.](https://www.semanticscholar.org/paper/The-information-capacity-of-the-human-motor-system-Fitts/634c9fde5f1c411e4487658ac738dcf18d98ea8d)
+
 ### Gall Yasası
 
 [Wikipedia'da Gall Yasası](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law)
 
-> Çalışan karmaşık bir sistemin her zaman işe yarayan daha basit bir sistemden evrimleştiği kesinlikle söylenebilir. Başlangıçtan itibaren karmaşık tasarlanmış bir sistemin asla çalışmayacağı ve sonradan da düzeltilemeyeceği kesindir. Çalışsan daha basit bir sistem ile başlamanız gerekir.
+> Çalışan karmaşık bir sistemin her zaman işe yarayan daha basit bir sistemden evrimleştiği kesinlikle söylenebilir. Başlangıçtan itibaren karmaşık tasarlanmış bir sistemin asla çalışmayacağı ve sonradan da düzeltilemeyeceği kesindir. Çalışsan daha basit bir sistem ile başlamanız gerekir. ([John Gall](https://en.wikipedia.org/wiki/John_Gall_(author)))
-> ([John Gall](https://en.m.wikipedia.org/wiki/John_Gall_(author)))
+> ([John Gall](https://en.wikipedia.org/wiki/John_Gall_(author)))
-> ([John Gall](https://en.m.wikipedia.org/wiki/John_Gall_(author)))
-> ([John Gall](https://en.m.wikipedia.org/wiki/John_Gall_(author)))
 
 Gall Yasası der ki, çok karmaşık sistemleri *tasarlamaya* çalışmak her zaman başarısızlıkla sonuçlanır. Bu tür sistemlerin ilk denemede başarılı olmaları çok nadir görülür ama genellikle basit sistemlerden evrilirler.
 
@@ -189,14 +247,12 @@ Ek kaynaklar:
 
 [Wikipedia'da Goodhart Yasası](https://en.wikipedia.org/wiki/Goodhart's_law)
 
-> Gözlemlenen herhangi bir istatistiksel düzenlilik, kontrol amaçları için üzerine baskı uygulandığında çökme eğiliminde olacaktır.
+> Gözlemlenen herhangi bir istatistiksel düzenlilik, kontrol amaçları için üzerine baskı uygulandığında çökme eğiliminde olacaktır. *Charles Goodhart*
-> *Charles Goodhart*
 > *Charles Goodhart*
 
 Ayrıca şu şekilde de ifade edilir:
 
-> Bir ölçüm hedef haline geldiğinde, iyi bir ölçüm olmaktan çıkar.
+> Bir ölçüm hedef haline geldiğinde, iyi bir ölçüm olmaktan çıkar. *Marilyn Strathern*
-> *Marilyn Strathern*
 > *Marilyn Strathern*
 
 Bu yasa, ölçüme dayalı optimizasyonların, ölçüm sonucunun kendisinin anlamsızlaşmasına yol açabileceğini belirtmektedir. Bir prosese kör bir şekilde uygulanan aşırı seçici tedbirler ( [KPI'ler](https://en.wikipedia.org/wiki/Performance_indicator) ) çarpık bir etkiye neden olur. İnsanlar, eylemlerinin bütünsel sonuçlarına dikkat etmek yerine belirli metrikleri tatmin etmek için sistemle "oynayarak" yerel olarak optimize etme eğilimindedir.
@@ -215,16 +271,39 @@ Ek kaynaklar:
 
 [Wikipedia'da Hanlon'un Usturası](https://en.wikipedia.org/wiki/Hanlon%27s_razor)
 
-> Aptallıkla layıkıyla açıklanabilecek bir şeyi, asla kötü niyete bağlamayın.
+> Aptallıkla layıkıyla açıklanabilecek bir şeyi, asla kötü niyete bağlamayın. Robert J. Hanlon
 > Robert J. Hanlon
 
 Bu prensip, olumsuz sonuçlara yol açan eylemlerin, çoğunlukla kötü niyetin sonucu olmadığını savunmaktadır. Aksine, olumsuz sonuç daha büyük olasılıkla bu eylemlerin ve/veya etkinin tam olarak anlaşılamamasına bağlıdır.
 
+### Hick Yasası (Hick-Hyman Yasası)
+
+[Wikipedia'da Hick Yasası](https://en.wikipedia.org/wiki/Hick%27s_law)
+
+> Karar verme süresi, seçebileceğiniz seçeneklerin sayısı ile logaritmik orantılı olarak büyür.
+> William Edmund Hick and Ray Hyman
+
+Aşağıdaki denklemde, `T` karar verme zamanıdır, `n` seçenek sayısıdır ve `b` verilerin analizi ile belirlenen bir sabittir.
+
+![Hicks law](./images/hicks_law.svg)
+
+*(Diagramın Kaynağı: Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/Hick%27s_law)*
+
+Bu yasa yalnızca seçeneklerin sayısı *sıralandığında* (örneğin alfabetik olarak) geçerlidir. Bu, temel iki logaritmada ima edilir - bu, karar vericinin aslında bir *ikili arama* gerçekleştirdiğini ima eder. Seçenekler iyi sıralanmamışsa, deneyler geçen sürenin doğrusal olduğunu gösterir.
+
+Bunun UI tasarımında önemli bir etkisi vardır; kullanıcıların seçenekleri kolayca arayabilmelerini sağlamak daha hızlı karar almayı sağlar.
+
+Hick Yasasında IQ ile reaksiyon süresi arasında [Bilgi İşleme Hızı: Gelişimsel Değişim ve İstihbarat Bağlantıları](https://www.sciencedirect.com/science/article/pii/S0022440599000369) makalesinde bahsedildiği gibi bir korelasyon da gösterilmiştir.
+
+Ek kaynaklar:
+
+- [Fitts Yasası](#fitts-law)
+
 ### Hofstadter Yasası
 
 [Wikipedia'da Hofstadter Yasası](https://en.wikipedia.org/wiki/Hofstadter%27s_law)
 
-> Bir iş her zaman umduğundan daha uzun sürer, Hofstadter yasasını göz önünde bulundursan bile.
+> Bir iş her zaman umduğundan daha uzun sürer, Hofstadter yasasını göz önünde bulundursan bile. (Douglas Hofstadter)
 > (Douglas Hofstadter)
 
 Bu yasayı bir işin ne kadar süreceğini tahminlenirken hatırlatıldığı için duymuş olabilirsiniz. Herkesin kabul ettiği bir gerçek var ki, yazılım geliştirmede en kötü olduğumuz alan işin ne kadar sürede biteceğini tahmin etmektir.
@@ -239,7 +318,7 @@ Ek kaynaklar:
 
 [Wikipedia'da Hutber Yasası ](https://en.wikipedia.org/wiki/Hutber%27s_law)
 
-> İyileştirme, bozulma anlamına da gelir.
+> İyileştirme, bozulma anlamına da gelir. ([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber))
 > ([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber))
 
 Bu yasa der ki; sistemde yapılan bir iyileştirme sistemin diğer taraflarında bozulmaya sebep olabilir ya da başka bozuklukları gizleyebilir, bu da sistemin mevcut durumunun daha da bozulmasına sebep olabilir.
@@ -250,12 +329,12 @@ Bu yasa der ki; sistemde yapılan bir iyileştirme sistemin diğer taraflarında
 
 [Wikipedia'da Hype Döngüsü](https://en.wikipedia.org/wiki/Hype_cycle)
 
-> Bir teknolojinin kısa vadede oluşacak etkisini abartıp, uzun vadede oluşacak etkisini hafife alıyoruz.
+> Bir teknolojinin kısa vadede oluşacak etkisini abartıp, uzun vadede oluşacak etkisini hafife alıyoruz. (Roy Amara) (Roy Amara)
 > (Roy Amara)
 
 Hype Döngüsü bir teknolojinin zamanla yarattığı heyecan ve gelişiminin görsel olarak sunumudur ve Gartner tarafından ilk olarak oluşturulmuştur. En güzel anlatım aşağıdaki bir görsel ile yapılabilir:
 
-![The Hype Cycle](../images/gartner_hype_cycle.png)
+![The Hype Cycle](./images/gartner_hype_cycle.png)
 
 *(Resmin Kaynağı: Jeremykemp tarafından İngilizce Wikipeda'da, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)*
 
@@ -275,6 +354,23 @@ Ek kaynaklar:
 - [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
 - [XKCD 1172](https://xkcd.com/1172/)
 
+### Kernighan Yasası
+
+> Kodda hata ayıklama yapmak, o kodun sıfırdan yazılmasından iki kat daha zordur. Dolayısıyla, yazdığın bir kodu hatasız yazdığını düşünüyorsan, tanım olarak o koddaki hatayı ayıklayacak kadar zeki değilsin demektir. (Brian Kernighan)
+> (Brian Kernighan)
+
+Kernighan Yasası adını [Brian Kernighan](https://en.wikipedia.org/wiki/Brian_Kernighan)'dan almıştır ve "[The Elements of Programming Style](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style)" adlı Kernighan ve Plauger tarafından yazılan kitaptaki bir cümleden türetilmiştir:
+
+> Herkes hata ayıklamanın kodu sıfırdan yazmaktan iki katı daha zor olduğunu bilir. Dolayısıyla, kodu yazarken bütün zekanızı kullanıp elinizden gelenin en iyisini yaptığınızda o koddaki hatayı daha sonra nasıl ayıklayabilirsiniz?
+
+Abartılı olmakla birlikte, Kernighan Yasası karmaşık kod yerine basit kodun tercih edileceği iddiasını ortaya koymaktadır, çünkü karmaşık kodda ortaya çıkan herhangi bir sorunu ayıklamak maliyetli veya hatta mümkün olmayabilir.
+
+Ek kaynaklar:
+
+- [KISS Prensibi](#the-kiss-principle)
+- [Unix Felsefesi](#the-unix-philosophy)
+- [Occam'ın Usturası](#occams-razor)
+
 ### Metcalfe Yasası
 
 [Wikipedia'da Metcalfe Yasası](https://en.wikipedia.org/wiki/Metcalfe's_law)
@@ -315,6 +411,24 @@ Ek kaynaklar:
 - [Doğrulama Önyargısı](#TODO)
 - [Seçim Tarafgirliği](#TODO)
 
+### Occam'ın Usturası
+
+[Wikipedia'da Occam'ın Usturası](https://en.wikipedia.org/wiki/Occam's_razor)
+
+> Çözümün elemanları sebep olmaksızın çoğaltılmamalıdır. Ockham'lı William
+> Ockham'lı William
+
+Occam'ın usturası, birkaç olası çözüm arasında en olası çözümün, en az sayıda kavram ve varsayımı olan çözüm olduğunu söylüyor. Bu çözüm en basit olandır ve yanlışlıkla ortaya çıkan karmaşıklığa ya da olası olumsuz sonuçlara sebep olmadan sadece verilen sorunu çözer.
+
+Ek kaynaklar:
+
+- [YAGNI](#yagni)
+- [Gümüş Bir Mermi Yok: Kazara Oluşan Karmaşıklık ve Gerekli Karmaşıklık](https://en.wikipedia.org/wiki/No_Silver_Bullet)
+
+Örnek:
+
+- [Yalın Yazılım Geliştirme: Çöpü Boşaltın](https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste)
+
 ### Parkinson Yasası
 
 [Wikipedia'da Parkinson Yasası](https://en.wikipedia.org/wiki/Parkinson%27s_law)
@@ -333,7 +447,7 @@ Ek kaynaklar:
 
 [WikiWikiWeb'de Olgunlaşmamış Optimizasyon Etkisi](http://wiki.c2.com/?PrematureOptimization)
 
-> Vakti gelmeden gelmeden yapılan optimizasyon bütün kötülüklerin anasıdır.
+> Vakti gelmeden gelmeden yapılan optimizasyon bütün kötülüklerin anasıdır. [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en)
 > [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en)
 
 Donald Knuth yazdığı [Structured Programming With Go To Statements](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements) isimli makalede, "Programcılar, programlarının kritik olmayan bölümlerinin hızını düşünerek veya endişelenerek çok fazla zaman harcarlar ve bu bakış açısı ile yaptıkları verimlilik geliştirmelerin hata ayıklama ve bakım yapma aşamalarına çok olumsuz etkileri olur. Kesinlikle bu tarz küçük geliştirmeleri (zamanımızın %97'sini harcadığımız) göz ardı etmeliyiz, **Vakti gelmeden yapılan optimizasyon bütün kötülüklerin anasıdır** gerçeğini unutmamalılıyız. Yine de, geride kalan % 3'teki kritik fırsatları kaçırmamalıyız."
@@ -382,11 +496,23 @@ Bir sistem ve yazılımdaki karmaşıklıkların bazıları dikkatsizlik veya ya
 
 O yasanın farklı bir yansıması olarak şöyle düşünülebilir, eğer bir karmaşıklık esastan geliyorsa ve sistem sadeleştirilerek bile ayıklanamıyorsa, daha karmaşık bir şekilde davranması beklenen *kullanıcının tarafına taşınabilir*.
 
+### Demeter Yasası
+
+[Wikipedia'da Demeter Yasası](https://en.wikipedia.org/wiki/Law_of_Demeter)
+
+> Asla yabancılarla konuşma.
+
+"En Az Bilgi İlkesi" olarak da bilinen Demeter Yasası, yazılım tasarımı için, özellikle nesne tabanlı dillerle ilgili bir ilkedir.
+
+Bir yazılım biriminin sadece en yakın işbirlikçileriyle konuşması gerektiğini belirtir. `B` nesnesine bir referansı olan bir `A` nesnesi yöntemlerini çağırabilir, ancak `B` `C` nesnesine bir referansı varsa, `A` `C` yöntemlerini direk çağırmamalıdır. Yani, eğer `C` bir `doThing()` yöntemine sahipse, `A` doğrudan çağırmamalıdır; `B.getC().doThis()`.
+
+Bu ilkeyi izlemek, değişikliklerin kapsamını sınırlayarak gelecekte değiştirmelerin daha kolay ve daha güvenli olmasını sağlar.
+
 ### Sızdıran Soyutlamalar Yasası
 
 [Sızdıran Soyutlamalar Yasası, Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/)
 
-> Önemsiz sayılmayacak bütün soyutlamar belli ölçüde sızıntı içerir.
+> Önemsiz sayılmayacak bütün soyutlamar belli ölçüde sızıntı içerir. ([Joel Spolsky](https://twitter.com/spolsky))
 > ([Joel Spolsky](https://twitter.com/spolsky))
 
 Bu yasa, karmaşık sistemleri sadeleştirmek için kullandığımız soyutlamaların bazı durumlarda soyutlamanın altındaki sistemin öğelerini sorunları ile birlikte sızdırır ve bu da beklenmedik davranışlar ortaya çıkması ile sonuçlanır.
@@ -431,6 +557,8 @@ Spotify Modeli Spotify'daki uygulamasından dolayı popüler olmuş ekip ve orga
 
 Spotify Modeli kabileler (Tribes), birlikler (Guilds) ve kısımlar (Chapter) gibi organizasyon yapısında kullanılacak öğeleri de yaygın hale getirdi.
 
+Organizasyonun üyeleri bu grupların gerçek anlamlarının zamanla değiştiğini, geliştiğini ve bunun devam eden bir deney olduğunu söylüyorlar. Modelin sabit bir modelden ziyade *hareket halinde bir süreç * olması, yapının değişen yorumlarına yol açmaya devam etmektedir (konferanslarda konuyla ilgili yapılan sunumlarına dayanarak söyleyebiliriz). Bu, 'anlık görüntülerin' üçüncü taraflar tarafından *sabit bir yapı * olarak yeniden paketlenebileceği anlamına gelir ve modelin dinamikliğinin kaybolmasına sebep olabilir.
+
 ### Wadler Yasası
 
 [Wadler Yasası, wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law)
@@ -439,8 +567,8 @@ Spotify Modeli kabileler (Tribes), birlikler (Guilds) ve kısımlar (Chapter) gi
 > 1. Semantik
 > 2. Genel sözdizimi
 > 3. Sözcük sözdizimi
-> 4. Yorumlardaki sözcük sözdizimi
+> 4. Yorumlardaki sözcük sözdizimi (Kısaca semantic için harcanan her bir saat için yorumlardaki sözcük sözdizimi için sekiz saat harcanacaktır).
-> (Kısaca semantic için harcanan her bir saat için yorumlardaki sözcük sözdizimi için sekiz saat harcanacaktır.)
+> (Kısaca semantic için harcanan her bir saat için yorumlardaki sözcük sözdizimi için sekiz saat harcanacaktır).
 
 [Önemsizlik Yasasında](#the-law-of-triviality) öne sürülene benzer olarak, Wadler Yasası yeni bir programlama dili tasarlanırken konunun önemi ile o konu için harcanan zaman ters orantılı olduğunu söylüyor.
 
@@ -454,7 +582,7 @@ Ek kaynaklar:
 
 [Resmi Gün](https://dontbeadickday.com/)
 
-> Öküzlük yapmayın.
+> Öküzlük yapmayın. *Wil Wheaton* *Wil Wheaton*
 > *Wil Wheaton*
 
 Wil Wheaton (Star Trek: The Next Generation, The Big Bang Theory) tarafından oluşturulan bu basit, özlü ve güçlü yasa, profesyonel bir organizasyon içinde uyum ve saygının artmasını amaçlamaktadır. İş arkadaşlarınızla konuşurken, kod incelemeleri yaparken, diğer bakış açılarını öne sürerken, insanları eleştirirken ve genel olarak insanların birbirleriyle olan profesyonel etkileşimlerinin çoğunda uygulanabilir.
@@ -463,14 +591,25 @@ Wil Wheaton (Star Trek: The Next Generation, The Big Bang Theory) tarafından ol
 
 Prensiplerin genellikle tasarıma ilişkin rehberlerdir.
 
+### Ölü Deniz Etkisi
+
+[Bruce F. Webster'e göre Ölü Deniz Etkisi](http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-dead-sea-effect/)
+
+> "... [E]n yetenekli ve verimli BT mühendisleri şirketleri terketmeye en yakın olanlardır, [kalıcı olma taraftarı olanlar] ise tortuya (daha az yetenekli ve verimsiz) benzetilebilir" *Bruce F. Webster*
+> *Bruce F. Webster*
+
+"Ölü Deniz Etkisi" bir organizasyonda mühendislerin becerilerinin/yeteneklerinin/verimliliklerinin  sıklıkla o organizasyonda harcadıkları zamanla ters orantılı olduğunu söyler.
+
+Genellikle, yüksek vasıflı mühendisler başka yerlerde iş bulması kolay kolay olan ve bunu ilk yapan kişilerdir. Eskimiş veya zayıf becerilere sahip mühendisler, başka bir yerde iş bulmak zor olduğu için şirkette kalma eğilimindedir. Bu, özellikle şirketteki zamanları boyunca artan ücret artışları elde ettikleri takdirde de geçerlidir, çünkü başka bir yerde eşdeğer ücret almaları zor olabilir.
+
 ### Dilbert Prensibi
 
 [Wikipedia'da Dilbert Prensibi](https://en.wikipedia.org/wiki/Dilbert_principle)
 
-> Şirketler, yetersiz çalışanları, iş akışından uzaklaştırmak için sistematik olarak yönetici olmaya teşvik etme eğilimindedir.
+> Şirketler, yetersiz çalışanları, iş akışından uzaklaştırmak için sistematik olarak yönetici olmaya teşvik etme eğilimindedir. *Scott Adams*
 > *Scott Adams*
 
-Scot Adams (Dilbert çizgi dizisinin yazarı) [Peter prensibinden](#the-peter-principle) esinlenerek ortaya atılmış bir yönetim kavramıdır. Dilbert prensibine göre yetenekli olmayan çalışanlar yönetim kadorlarına dopru yükseltilirler ki üretime verecekleri zarar aza indirilsin. Adams bunu ilk olarak 1995'te Wall Street Journal'da yazdığı bir makalede açıkladı daha sonra ise 1996'da yazdığı [Dilbert Prensibi](#reading-list) adlı kitabında detaylandırdı.
+Scot Adams (Dilbert çizgi dizisinin yazarı) [Peter prensibinden](#the-peter-principle) esinlenerek ortaya atılmış bir yönetim kavramıdır. Dilbert prensibine göre yetenekli olmayan çalışanlar yönetim kadorlarına doğru yükseltilirler ki üretime verecekleri zarar aza indirilsin. Adams bunu ilk olarak 1995'te Wall Street Journal'da yazdığı bir makalede açıkladı daha sonra ise 1996'da yazdığı [Dilbert Prensibi](#reading-list) adlı kitabında detaylandırdı.
 
 Ek kaynaklar:
 
@@ -493,7 +632,6 @@ Pareto Prensibi der ki, çıktıların önemli bir çoğunluğu girdilerin çok
 
 1940'lı yıllarda Romanya kökenli Amerikalı mühendis Dr. Joseph Juran, kendisi kalite kontrolün babası olarak nitelendirilir, [kalite kontrol sorunlarında Pareto Prensibini kullanmaya başladı](https://en.wikipedia.org/wiki/Joseph_M._Juran).
 
-
 Bu prensip aynı zamanda 80/20 Kuralı (The Law of the Vital Few and The Principle of Factor Sparsity) olarak da bilinir.
 
 Gerçek dünyadan örnekler:
@@ -504,7 +642,7 @@ Gerçek dünyadan örnekler:
 
 [Wikipedia'da Peter Prensibi](https://en.wikipedia.org/wiki/Peter_principle)
 
-> Hiyerarşideki insanlar “yetersizlik seviyelerine” göre yükselme eğilimindedir.
+> Hiyerarşideki insanlar “yetersizlik seviyelerine” göre yükselme eğilimindedir. *Laurence J. Peter* *Laurence J. Peter*
 > *Laurence J. Peter*
 
 Laurence J. Peter tarafından geliştirilen bir yönetim konsepti olan Peter Prensibi, işlerinde iyi olan kişilerin, artık başarılı olamadıkları bir seviyeye (kendi "yetersizlik seviyelerine") ulaşana kadar terfi ettiğini gözlemlemektedir. Bu durumda şirket içinde çok tecrübeli olduklarından organizasyondan (çok aykırı birşey yapmadıkları sürece) dışlanmazlar ve az sayıda temel beceriye sahip olacakları bir rolde kalmaya devam edecekler, çünkü onları başarılı kılan orijinal becerileri mutlaka bu yeni rolleri için gereken beceriler değildir.
@@ -526,6 +664,12 @@ Genellikle sunucu uygulamaları geliştirirken uygulanabilir. Bu prensip der ki;
 
 Bu prensibin amacı dayanıklı sistemlere geliştirmektir ve bu sistemler kötü yapılandırılmış girdileri bile anlayabildikleri durumda işleyebilmeliler. Bunun güvenlik açısından kötü amaçlı ve yeterince kontrol edilmemiş girdileri kabul etmek anlamına gelebileceği için riskli olduğu düşünülebilir. Tabiki bu riskin de göz önünde bulundurulması gerekir.
 
+Uygun olmayan girdilere zaman içinde izin verilmesi, uygulayıcıların yeni özellikler oluştururken bu serbestliğe güvenmesini sağlayacağından en sonunda protokollerin evrimleşme yeteneğini zayıflatabilir.
+
+Ek kaynaklar:
+
+- [Hyrum Yasası](#hyrums-law-the-law-of-implicit-interfaces)
+
 ### SOLID
 
 SOLID aşağıdaki beş prensibin baş harflerinden oluşan bir kısaltmadır;
@@ -546,7 +690,7 @@ Bunları [Nesne Tabanlı Proglamlama'nın](#todo) temel prensipleri olarak değe
 
 Bu '[SOLID](#solid)' prensiplerinin ilkidir. Bu prensip der ki her bir sistem parçasının yada programlama sınıfının sadece ama sadece bir sorumluluğu olması gerekir. Daha sade anlatmak gerekirse, bir programdaki sadece bir özelliği etkileyen bir değişiklik sadece o özelliği ilgilendiren parça ya da sınıfta yapılmalı. Örneğin, şifrelerin doğruluğunun kontrolünde bir değiştirme yapılacaksa sadece programın o bölümünde değişiklik yapılmalı.
 
-Teorik olarak, bu prensibe uygun yazılmış kodlar daha sağlam ve değiştirilmesi kolaydır. Sadece tek bir parçanın değiştirildiğine emin olunduğunda değişimi *tesk etmek* de kolay olacaktır. Önceki şifre örneğini düşünürsek, şifrenin zorluk seviyesi değiştirildiğinde sadece şifre ilgili bölümlerin etkilenecektir. Birden fazla sorumluluğu olan bir bölümde olan değişikliğin nereleri etkileceğini hesaplamak daha zordur.
+Teorik olarak, bu prensibe uygun yazılmış kodlar daha sağlam ve değiştirilmesi kolaydır. Sadece tek bir parçanın değiştirildiğine emin olunduğunda değişimi *test etmek* de kolay olacaktır. Önceki şifre örneğini düşünürsek, şifrenin zorluk seviyesi değiştirildiğinde sadece şifre ilgili bölümlerin etkilenecektir. Birden fazla sorumluluğu olan bir bölümde olan değişikliğin nereleri etkileceğini hesaplamak daha zordur.
 
 Ek kaynaklar:
 
@@ -563,7 +707,6 @@ Bu '[SOLID](#solid)' prensiplerinin ikincisidir ve herhangi bir sistem parçası
 
 Örneğin Markdown formatındaki belgeleri HTML formatına çeviren bir modülü düşünelim. Eğer bu modül kendisi değiştirilmeden yeni bir Markdown formatını da işlemesi sağlanacak şekilde geliştirilebiliyorsa, bu modül genişletilmeye açık demektir. Eğer sonradan değiştirilip Markdown formatı işlemesi ile ilgili geliştirme *yapılamıyorsa*, bu modül değiştirilmeye *kapalı* demektir.
 
-
 Bu prensip nesne-tabanlı programlamaya tam uygundur. Şöyle ki, kendi nesne ve sınıflarımızı miras alınarak geliştirmeye uygun ve değiştirmeye ihtiyaç duymayacak şekilde tasarlarsak ve yazarsak nesne-tabanlı programlamaya tam uygun kod yazmış oluruz.
 
 Ek kaynaklar:
@@ -619,7 +762,6 @@ Ek kaynaklar:
 
 Bu prensip olması gereken bağımlığı tersine çevirdiği düşünebileceğinden (isminden dolayı) biraz karmaşık gelebilir. Pratikte, ayrı bir düzenleme bileşeninin, soyut türlerin doğru uygulamalarının kullanılmasını sağlaması gerektiği anlamına gelir (önceki örnekte, *bir şey* hala meta veri okuyucu bileşenine bir HTTP dosyası indiricisi ve HTML meta etiketi okuyucu sağlamalıdır). Bu prensip aynı zamanda [Kontrolün Ters Çevirilmesi](#todo) ve [Bağımlık Enjeksiyonu](#todo) gibi konularla da bağlantılıdır.
 
-
 Ek kaynaklar:
 
 - [Nesne Tabanlı Programlama](#todo)
@@ -635,7 +777,6 @@ Ek kaynaklar:
 
 *DRY Don't Repeat Yourself* yani Kendini Tekrar Etme deyimin kısaltılmasıdır. İlk olarak Andrew Hunt ve Dave Thomas tarafından [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) kitabında bahsedilmiştir. Bu ilke, geliştiricilere kod tekrarını azaltma ve bilgileri tek bir yerde tutmalarına yardımcı olmayı amaçlamaktadır.
 
-
 > DRY'nin tam tersi *WET* olacaktır (Write Everything Twice (Her Şeyi İki Kez Yaz) We Enjoy Typing (Yazmayı Seviyoruz)).
 
 Uygulamada, aynı bilgi parçasını iki (veya daha fazla) farklı yerde kullanıyorsanız, DRY'yi bunları tek bir tanede birleştirmek ve istediğiniz / ihtiyaç duyduğunuz yerde tekrar kullanmak için kullanabilirsiniz.
@@ -664,8 +805,8 @@ Ek kaynaklar:
 
 ***Y**ou **A**ren't **G**onna **N**eed **I**t* (İhtiyacın olmayacak) deyiminin kısaltmasıdır.
 
-> İhtiyaç duyduğunuz şeyleri her zaman ihtiyaç duyduğunuzda geliştirin, onlara ihtiyacınız olacağını düşündüğünüzde değil.
+> İhtiyaç duyduğunuz şeyleri her zaman ihtiyaç duyduğunuzda geliştirin, onlara ihtiyacınız olacağını düşündüğünüzde değil. ([Ron Jeffries](https://twitter.com/RonJeffries)) (XP co-founder and author of the book "Extreme Programming Installed")
-> ([Ron Jeffries](https://twitter.com/RonJeffries)) (XP eş-kurucusu and "Extreme Programming Installed" kitabının yazarı)
+> ([Ron Jeffries](https://twitter.com/RonJeffries)) (XP co-founder and author of the book "Extreme Programming Installed")
 
 Bu *Aşırı Programlama* (XP) ilkesi, geliştiricilerin yalnızca acil gereksinimler için gerekli olan işlevleri yerine getirmeleri gerektiğini ve daha sonra ihtiyaç duyulabilecek işlevleri uygulayarak geleceği tahmin etme girişimlerinden kaçınmalarını önerir.
 
@@ -677,7 +818,7 @@ Ek kaynaklar:
 
 ### Dağıtık Sistemlerin Yanılgıları
 
-[Wikipedia'da Dağıtık Sistemlerin Yanılgıları](https://en.wikipedia.org/wiki/You_aren%https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing)
+[Wikipedia'da Dağıtık Sistemlerin Yanılgıları](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing)
 
 *Ağ Tabanlı Sistemlerin Yanılgıları* olarak da bilinen yanılgılar dağıtık sistemleri geliştirme sırasında başarısızlıklara yol açabilecek varsayımların (veya inançların) bir listesidir. Varsayımlar:
 
@@ -698,8 +839,7 @@ Dayanıklı sistemler tasarlarken bu yanılgılar dikkatlice ele alınmalı; bu
 
 Ek kaynaklar:
 
-- [Foraging for the Fallacies of Distributed Computing (Part 1) - Vaidehi Joshi
+- [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)
-    on Medium](https://medium.com/baseds/foraging-for-the-fallacies-of-distributed-computing-part-1-1b35c3b85b53)
 - [Deutsch's Fallacies, 10 Years After](http://java.sys-con.com/node/38665)
 
 ## Ek Kaynaklar
@@ -712,6 +852,33 @@ Bu kavramları ilginç bulduysanız, aşağıdaki kitapların keyfini çıkarabi
 - [Dilbert Prensibi - Scott Adams](https://www.goodreads.com/book/show/85574.The_Dilbert_Principle) - [Dilbert İlkesini](#the-dilbert-principle) oluşturan yazardan, kurumsal Amerika'ya komik bir bakış.
 - [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).
 
+## Çeviriler:
+
+Katkıda bulunan harika insanlar sayesinde Hacker Laws birçok dilde mevcuttur. Lütfen çeviri sahiplerine de sponsor olmayı düşünün!
+
+Dil | Moderatör | Durum
+--- | --- | ---
+[🇮🇩 Bahasa Indonesia / Indonesian](./translations/pt-BR.md) | [arywidiantara](https://github.com/arywidiantara) | [](https://gitlocalize.com/repo/2513/id?utm_source=badge)![gitlocalized ](https://gitlocalize.com/repo/2513/id/badge.svg)
+[🇧🇷 Brasileiro / Brazilian](./translations/pt-BR.md) | [Leonardo Costa](https://github.com/leofc97) | [](https://gitlocalize.com/repo/2513/id?utm_source=badge)![gitlocalized ](https://gitlocalize.com/repo/2513/id/badge.svg)
+[🇨🇳 中文 / Chinese](https://github.com/nusr/hacker-laws-zh) | [Steve Xu](https://github.com/nusr) | Kısmen tamamlandı
+[🇩🇪 Deutsch / German](./translations/de.md) | [Vikto](https://github.com/viktodergunov) | [](https://gitlocalize.com/repo/2513/lv?utm_source=badge)[](https://gitlocalize.com/repo/2513/tr?utm_source=badge)![gitlocalized ](https://gitlocalize.com/repo/2513/tr/badge.svg)[![gitlocalized ](https://gitlocalize.com/repo/2513/lv/badge.svg)](https://gitlocalize.com/repo/2513/lv?utm_source=badge)
+[🇫🇷 Français / French](./translations/fr.md) | [Kevin Bockelandt](https://github.com/KevinBockelandt) | [](https://gitlocalize.com/repo/2513/tr?utm_source=badge)![gitlocalized ](https://gitlocalize.com/repo/2513/tr/badge.svg)
+[🇬🇷 ελληνικά / Greek](./translations/el.md) | [Panagiotis Gourgaris](https://github.com/0gap) | [](https://gitlocalize.com/repo/2513/ja?utm_source=badge)[](https://gitlocalize.com/repo/2513/lv?utm_source=badge)![gitlocalized ](https://gitlocalize.com/repo/2513/lv/badge.svg)[![gitlocalized ](https://gitlocalize.com/repo/2513/ja/badge.svg)](https://gitlocalize.com/repo/2513/ja?utm_source=badge)
+[🇮🇹 Italiano / Italian](https://github.com/csparpa/hacker-laws-it) | [Claudio Sparpaglione](https://github.com/csparpa) | Kısmen tamamlandı
+[🇯🇵 JP 日本語 / Japanese](./translations/jp.md) | [Fumikazu Fujiwara](https://github.com/freddiefujiwara) | [](https://gitlocalize.com/repo/2513/fr?utm_source=badge)![gitlocalized ](https://gitlocalize.com/repo/2513/fr/badge.svg)
+[🇰🇷 한국어 / Korean](https://github.com/codeanddonuts/hacker-laws-kr) | [Doughnut](https://github.com/codeanddonuts) | Kısmen tamamlandı
+[🇱🇻 Latviešu Valoda / Latvian](./translations/lv.md) | [Arturs Jansons](https://github.com/iegik) | [](https://gitlocalize.com/repo/2513/de?utm_source=badge)![gitlocalized ](https://gitlocalize.com/repo/2513/de/badge.svg)
+[🇷🇺 Русская версия / Russian](https://github.com/solarrust/hacker-laws) | [Alena Batitskaya](https://github.com/solarrust) | Kısmen tamamlandı
+[🇪🇸 Castellano / Spanish](./translations/es-ES.md) | [Manuel Rubio](https://github.com/manuel-rubio) ([Sponsor](https://github.com/sponsors/manuel-rubio)) | Kısmen tamamlandı
+[🇹🇷 Türkçe / Turkish](https://github.com/umutphp/hacker-laws-tr) | [Umut Işık](https://github.com/umutphp) | [](https://gitlocalize.com/repo/2513/id?utm_source=badge)![gitlocalized ](https://gitlocalize.com/repo/2513/id/badge.svg)
+
+Bir çeviriyi güncellemek isterseniz, [bir PR açmanız yeterlidir](https://github.com/dwmkerr/hacker-laws/pulls) . Yeni bir dil eklemek istiyorsanız, bir hesap oluşturmak için [GitLocalize'a](https://gitlocalize.com/) giriş yapın, ardından dili yönetmek istediğinizi belirten bir Issue açın; sizi projeye ekleyeceğim! Yukarıdaki tabloyu güncelleyen bir PR açabilmeniz de çok yararlı olacaktır.
+
+## İlgili Projeler
+
+- [Tip of the Day](https://tips.darekkay.com/html/hacker-laws-en.html) - Hergün bir hacker yasası ya da prensibi.
+- [Hacker Laws CLI](https://github.com/umutphp/hacker-laws-cli) - Terminalden yasaları listeleyin, ve rastgele bir yasa görüntüleyin!
+
 ## Katkıda Bulunmak İçin
 
 Lütfen katkıda bulunun! Bir ekleme veya değişiklik önermek istiyorsanız [bir sorun oluşturun](https://github.com/dwmkerr/hacker-laws/issues/new) veya kendi değişikliklerinizi önermek için [bir PR açın](https://github.com/dwmkerr/hacker-laws/compare) .
@@ -723,4 +890,3 @@ Lütfen metin, stil ve benzeri gereksinimler için [Katkıda Bulunma Kılavuzunu
 Selam!. Buraya ulaştıysanız, henüz yazmadığım bir konunun bağlantısını tıkladınız, bunun için üzgünüm - ve en kısa zamanda tamamlamaya çalışacağım!
 
 Soru ve önerileriniz için [issue](https://github.com/dwmkerr/hacker-laws/issues) açabilirsiniz, ya da katkıda bulunmak isterseniz [Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) açabilirsiniz.
-