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

chore(main): release 0.3.0

.github/CHANGELOG.md

@@ -0,0 +1,41 @@
+# Changelog
+
+## [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/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.0"
+}

.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,66 +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.
+---
 
-[Translations](#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)
+- 📖 My new book [Effective Shell](https://effective-shell) on [Amazon](https://amzn.to/4ho0F91)
-
+- 🌍 Try [hacker-laws.com](https://hacker-laws.com)
-Like this project? Please considering [sponsoring me](https://github.com/sponsors/dwmkerr) and the [translators](#translations).
+- 🧠 Check out my new project [Terminal AI](https://github.com/dwmkerr/terminal-ai)
+- ☕️ Like this project? Consider [buying me a coffee with a one-off donation](https://github.com/sponsors/dwmkerr?frequency=one-time)
+- 🎧 Listen to the podcast [The Changelog - Laws for Hackers to Live By](https://changelog.com/podcast/403)
+- 📖 Download the [PDF eBook](https://github.com/dwmkerr/hacker-laws/releases/latest/download/hacker-laws.pd)
+- 🌏 See the [Translations](#translations)
 
 ---
 
 <!-- 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)
-    * [Kernighan's Law](#kernighans-law)
+    - [Goodhart's Law](#goodharts-law)
-    * [Metcalfe's Law](#metcalfes-law)
+    - [Hanlon's Razor](#hanlons-razor)
-    * [Moore's Law](#moores-law)
+    - [Hick's Law (Hick-Hyman Law)](#hicks-law-hick-hyman-law)
-    * [Murphy's Law / Sod's Law](#murphys-law--sods-law)
+    - [Hofstadter's Law](#hofstadters-law)
-    * [Occam's Razor](#occams-razor)
+    - [Hutber's Law](#hutbers-law)
-    * [Parkinson's Law](#parkinsons-law)
+    - [The Hype Cycle & Amara's Law](#the-hype-cycle--amaras-law)
-    * [Premature Optimization Effect](#premature-optimization-effect)
+    - [Hyrum's Law (The Law of Implicit Interfaces)](#hyrums-law-the-law-of-implicit-interfaces)
-    * [Putt's Law](#putts-law)
+    - [Input-Process-Output (IPO)](#input-process-output-ipo)
-    * [Reed's Law](#reeds-law)
+    - [Kernighan's Law](#kernighans-law)
-    * [The Law of Conservation of Complexity (Tesler's Law)](#the-law-of-conservation-of-complexity-teslers-law)
+    - [Koomey's Law](#koomeys-law)
-    * [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
+    - [Linus's Law](#linuss-law)
-    * [The Law of Triviality](#the-law-of-triviality)
+    - [Metcalfe's Law](#metcalfes-law)
-    * [The Unix Philosophy](#the-unix-philosophy)
+    - [Moore's Law](#moores-law)
-    * [The Spotify Model](#the-spotify-model)
+    - [Murphy's Law / Sod's Law](#murphys-law--sods-law)
-    * [Wadler's Law](#wadlers-law)
+    - [Occam's Razor](#occams-razor)
-    * [Wheaton's Law](#wheatons-law)
+    - [Parkinson's Law](#parkinsons-law)
-* [Principles](#principles)
+    - [Premature Optimization Effect](#premature-optimization-effect)
-    * [The Dilbert Principle](#the-dilbert-principle)
+    - [Putt's Law](#putts-law)
-    * [The Pareto Principle (The 80/20 Rule)](#the-pareto-principle-the-8020-rule)
+    - [Reed's Law](#reeds-law)
-    * [The Peter Principle](#the-peter-principle)
+    - [The Bitter Lesson](#the-bitter-lesson)
-    * [The Robustness Principle (Postel's Law)](#the-robustness-principle-postels-law)
+    - [The Ringelmann Effect](#the-ringelmann-effect)
-    * [SOLID](#solid)
+    - [The Law of Conservation of Complexity (Tesler's Law)](#the-law-of-conservation-of-complexity-teslers-law)
-    * [The Single Responsibility Principle](#the-single-responsibility-principle)
+    - [The Law of Demeter](#the-law-of-demeter)
-    * [The Open/Closed Principle](#the-openclosed-principle)
+    - [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
-    * [The Liskov Substitution Principle](#the-liskov-substitution-principle)
+    - [The Law of the Instrument](#the-law-of-the-instrument)
-    * [The Interface Segregation Principle](#the-interface-segregation-principle)
+    - [The Law of Triviality](#the-law-of-triviality)
-    * [The Dependency Inversion Principle](#the-dependency-inversion-principle)
+    - [The Unix Philosophy](#the-unix-philosophy)
-    * [The DRY Principle](#the-dry-principle)
+    - [The Scout Rule](#the-scout-rule)
-    * [The KISS principle](#the-kiss-principle)
+    - [The Spotify Model](#the-spotify-model)
-    * [YAGNI](#yagni)
+    - [The Two Pizza Rule](#the-two-pizza-rule)
-    * [The Fallacies of Distributed Computing](#the-fallacies-of-distributed-computing)
+    - [Twyman's law](#twymans-law)
-* [Reading List](#reading-list)
+    - [Wadler's Law](#wadlers-law)
-* [Translations](#translations)
+    - [Wheaton's Law](#wheatons-law)
-* [Related Projects](#related-projects)
+- [Principles](#principles)
-* [Contributing](#contributing)
+    - [All Models Are Wrong (George Box's Law)](#all-models-are-wrong-george-boxs-law)
-* [TODO](#todo)
+    - [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 -->
 
@@ -68,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
 
@@ -86,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.
 
@@ -111,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/)
 
@@ -121,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.
 
@@ -132,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:
 
@@ -160,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)
@@ -216,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)
@@ -256,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".
 
@@ -271,13 +416,30 @@ 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.
@@ -296,6 +458,41 @@ See also:
 - [The Unix Philosophy](#the-unix-philosophy)
 - [Occam's Razor](#occams-razor)
 
+### Koomey's Law
+
+[Koomey's Law on Wikipedia](https://en.wikipedia.org/wiki/Koomey%27s_law)
+
+> ...at a fixed computing load, the amount of battery you need will fall by a factor of two every year and a half.
+>
+> (Jonathan Koomey)
+
+In 2010 Professor Jonathan Koomey discovered that the trend in number of computations per joule of energy dissipated had been remarkably stable. This trend became known as Koomey's Law - that the amount of battery needed for a given computing load would half each 2.5 years.
+
+Koomey performed a follow-up analysis in 2010 and found that this trend had slowed, similar to how [Moore's Law](#moores-law) had slowed. This seemed to be related to limitations around how small transistors can be made, as well as [Dennard Scaling](https://en.wikipedia.org/wiki/Dennard_scaling).
+
+See also:
+
+- [Moore's Law](#moores-law)
+- [Dennard Scaling](https://en.wikipedia.org/wiki/Dennard_scaling)
+
+### Linus's Law
+
+[Linus's Law on Wikipedia](https://en.wikipedia.org/wiki/Linus%27s_law)
+
+> Given enough eyeballs, all bugs are shallow.
+>
+> _Eric S. Raymond_
+
+This law simply states that the more people who can see a problem, the higher the likelihood that someone will have seen and solved the problem before, or something very similar.
+
+Although it was originally used to describe the value of open-source models for projects it can be accepted for any kind of software project. It can also be extended to processes - more code reviews, more static analysis and multi-disciplined test processes will make the problems more visible and easy to identify.
+
+A more formal statement can be:
+
+> Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and can be solved by someone who has encountered a similar problem before.
+
+This law was named in honour of [Linus Torvalds](https://en.wikipedia.org/wiki/Linus_Torvalds) in Eric S. Raymond's book "[The Cathedral and the Bazaar](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar)".
+
 ### Metcalfe's Law
 
 [Metcalfe's Law on Wikipedia](https://en.wikipedia.org/wiki/Metcalfe's_law)
@@ -316,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)
@@ -362,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:
 
@@ -370,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.
 
@@ -399,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)
@@ -412,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)
@@ -422,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/)
@@ -432,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.
 
@@ -446,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)
@@ -464,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/)
@@ -472,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)
@@ -507,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)
@@ -544,6 +893,25 @@ 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)
@@ -552,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:
 
@@ -569,7 +937,7 @@ See Also:
 
 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.
 
@@ -577,16 +945,10 @@ 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.
 
@@ -598,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:
 
@@ -613,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 now 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.
 
@@ -630,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.
 
@@ -664,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.
 
@@ -683,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).
 
@@ -691,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
 
@@ -711,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.
 >
@@ -742,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.
 
@@ -750,50 +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).
 
-## Translations
+## Online Resources
 
-Thanks to a number of wonderful contributors, Hacker Laws is available in a number of languages. Please consider sponsoring moderators!
+Some useful resources and reading.
 
-| Language | Moderator | Status |
+- [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.
-|----------|-----------|--------|
-| [🇧🇷 Brasileiro / Brazilian](./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) |
-| [🇨🇳 中文 / 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) |
-| [🇫🇷 Français / French](./translationis/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) | 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) |
-| [🇷🇺 Русская версия / 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) |
 
-If you would like to update a translation, just [open a pull request](https://github.com/dwmkerr/hacker-laws/pulls). If you want to add a new language, log onto [GitLocalize](https://gitlocalize.com/) to create an account, then open an issue asking to administer the language and I will add you to the project! It would also be super helpful if you can open a pull request which updates the table above and link at the top of the file.
+## PDF eBook
 
-## Related Projects
+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.
 
-- [Tip of the Day](https://tips.darekkay.com/html/hacker-laws-en.html) - Receive a daily hacker law/principle.
+A new version of the eBook is created automatically when a new version tag is pushed.
 
-## Contributing
+## Podcast
 
-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.
+Hacker Laws has been featured in [The Changelog](https://changelog.com/podcast/403), you can check out the Podcast episode with the link below:
 
-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.
+<a href="https://changelog.com/podcast/403" target="_blank"><img src="./images/changelog-podcast.png" width="800px" alt="Changelog Podcast Image" /></a>
 
-## TODO
-
-Hi! If you land here, you've clicked on a link to a topic I've not written up yet, sorry about this - this is work in progress!
-
-Feel free to [Raise an Issue](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

@@ -193,7 +193,7 @@ 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 effect globaux de leurs actions sur le système.
+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 :
 
@@ -244,7 +244,7 @@ Par exemple, un abaissement de la latence de réponse sur une route (end-point)
 
 [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 surestimer sur le long terme.
+> 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 :
@@ -259,7 +259,7 @@ En clair, ce cycle montre qu'il y a généralement un pic d'excitation concernan
 
 [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.
+> 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.
@@ -486,7 +486,7 @@ Voir aussi :
 > 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 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.
+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
 
@@ -499,7 +499,7 @@ Les principes sont généralement des lignes directrices liés à la conception.
 > 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 limité 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).
+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 :
 
@@ -593,7 +593,7 @@ Voir aussi :
 
 > 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.) devraient pouvoir être *étendu*, mais que le comportement *existant* ne devrait pas pouvoir être modifié.
+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é.
 
@@ -679,7 +679,7 @@ Voir aussi :
 
 [KISS sur Wikipedia](https://fr.wikipedia.org/wiki/Principe_KISS)
 
-> > Keep it simple, stupid. (Ne complique pas les choses)
+> 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.
 
@@ -700,7 +700,7 @@ Il s'agit d'un acronyme pour ***Y**ou **A**in't **G**onna **N**eed **I**t*. Que
 
 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 la codebase et permettre d'éviter de passer du temps et des efforts sur des fonctionnalités qui n'apportent rien.
+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 :
 

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/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,19 +105,35 @@ 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 Brooks, principalmente porque algumas tarefas não 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 Brooke, principalmente porque algumas tarefas nao podem ser divididas.
+Esse é um tema central do livro '[The Mythical Man Month](#lista-de-livros)'.
-
-
-Esse é um tema central do livro'[The Mythical Man Month](#lista-de-livros)'.
 
 Veja também:
 
@@ -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,13 +238,24 @@ 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.
+> Nós tendemos a superestimar os efeitos da tecnologia em curto prazo e subestimar os efeitos a longo prazo.
 >
 > Roy Amara
 
@@ -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 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 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 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".
+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,
->Com um número suficientes de clientes de uma API,
+> não importa a sua pré-condição no contato:
->não importa a sua pré-condição no contato:
+> todos os comportamentos observáveis do seu sistema
->todos os comportamentos observáveis do seu sistema
+> serão dependentes de alguém.
->serão dependentes de alguém.
 >
-> (Hyrum Wright)
+> Hyrum Wright
 
-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 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,13 +329,63 @@ 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)
 
 >O trabalho se expande de modo a preencher o tempo disponível para a sua realização.
 
-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.
+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
 
@@ -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,7 +2,7 @@
 
 Programcıların faydalı bulacağı yasalar, teoriler, prensipler ve desenler.
 
-[Çeviriler](#%C3%A7eviriler): [🇧🇷](./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)
+[Ç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)
 
 Bu projeyi beğendiniz mi? Lütfen [sponsor olmayı](https://github.com/sponsors/dwmkerr) düşünün!
 
@@ -10,31 +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ı](#kernighan-yasas%C4%B1)
+    - [Kernighan Yasası](#kernighans-law)
     - [Metcalfe Yasası](#metcalfes-law)
     - [Moore Yasası](#moores-law)
     - [Murphy Yasası / Sod  Yasası](#murphys-law--sods-law)
-    - [Occam'ın Usturası](#occam%C4%B1n-usturas%C4%B1)
+    - [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)
@@ -42,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)
@@ -55,11 +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)
-- [Çeviriler](#%C3%A7eviriler)
+- [Çeviriler](#translations)
-- [Katkıda Bulunmak İçin](#katk%C4%B1da-bulunmak-i%CC%87%C3%A7in)
+- [Katkıda Bulunmak İçin](#related-projects)
-- [Katkıda Bulunmak İçin](#katk%C4%B1)
+- [Katkıda Bulunmak İçin](#contributing)
 - [TODO](#todo)
 
 <!-- vim-markdown-toc -->
@@ -74,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)
@@ -84,8 +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)*
 
@@ -108,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:
 
@@ -133,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)
@@ -167,11 +210,29 @@ 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.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.
@@ -186,12 +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*
 
 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*
 
 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.
@@ -210,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.
@@ -234,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.
@@ -245,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)*
 
@@ -272,7 +356,7 @@ Ek kaynaklar:
 
 ### 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.
+> 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:
@@ -283,9 +367,9 @@ Abartılı olmakla birlikte, Kernighan Yasası karmaşık kod yerine basit kodun
 
 Ek kaynaklar:
 
-- [KISS Prensibi](#kiss-prensibi)
+- [KISS Prensibi](#the-kiss-principle)
-- [Unix Felsefesi](#unix-felsefesi)
+- [Unix Felsefesi](#the-unix-philosophy)
-- [Occam'ın Usturası](#occam%C4%B1n-usturas%C4%B1)
+- [Occam'ın Usturası](#occams-razor)
 
 ### Metcalfe Yasası
 
@@ -331,7 +415,7 @@ Ek kaynaklar:
 
 [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.
+> Çö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.
@@ -363,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."
@@ -412,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.
@@ -461,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)
@@ -469,7 +567,7 @@ 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).
 
 [Ö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.
@@ -484,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.
@@ -493,11 +591,22 @@ 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 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ı.
@@ -533,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.
@@ -559,7 +668,7 @@ Uygun olmayan girdilere zaman içinde izin verilmesi, uygulayıcıların yeni ö
 
 Ek kaynaklar:
 
-- [Hyrum Yasası](#hyrum-yasas%C4%B1-arabirimlerin-%C3%B6rt%C3%BCl%C3%BC-hukuku)
+- [Hyrum Yasası](#hyrums-law-the-law-of-implicit-interfaces)
 
 ### SOLID
 
@@ -696,7 +805,7 @@ 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 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.
@@ -709,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:
 
@@ -749,23 +858,26 @@ Katkıda bulunan harika insanlar sayesinde Hacker Laws birçok dilde mevcuttur.
 
 Dil | Moderatör | Durum
 --- | --- | ---
-[🇧🇷 Brasileiro / Brazilian](./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)
+[🇮🇩 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) | [![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)
+[🇩🇪 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](./translationis/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)
+[🇫🇷 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) | [![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)
+[🇬🇷 ελληνικά / 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) | [![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)
+[🇱🇻 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) | [![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)
+[🇹🇷 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