chore: minor tweak of occam's razor text

Occam's Razor

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,76 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, sex characteristics, gender identity and expression,
+level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+ advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+ address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+ professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at dwmkerr@gmail.com. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+https://www.contributor-covenant.org/faq

.github/FUNDING.yml

@@ -0,0 +1,2 @@
+# Support 'GitHub Sponsors' funding.
+github: dwmkerr

.github/contributing.md

@@ -0,0 +1,63 @@
+# Contributing Guidelines
+
+<!-- vim-markdown-toc GFM -->
+
+* [Example Law: The Law of Leaky Abstractions](#example-law-the-law-of-leaky-abstractions)
+* [Localisation](#localisation)
+
+<!-- vim-markdown-toc -->
+
+The goal of this project is to have a set of _concise_ definitions to laws, principles, methodologies and patterns which hackers will find useful. They should be:
+
+1. Short - one or two paragraphs.
+2. Include the original source.
+3. Quote the law if possible, with the author's name.
+4. Link to related laws in the 'See also' section.
+5. Include real-world examples if possible in the 'Real-world examples' section.
+
+Some other tips:
+
+- It is fine to include laws which are humorous or not serious.
+- If a law does not obviously apply to development or coding, include a paragraph explaining the relevance to technologists.
+- Don't worry about managing the table of contents, I can generate it.
+- Feel free to include images, but aim to keep it down to one image per law.
+- Be careful not to copy-and-paste content (unless it is explicitly quoted), as it might violate copyright.
+- Include hyperlinks to referenced material.
+- Do not advocate for the law, or aim to be opinionated on the correctness or incorrectness of the law, as this repository is simply the descriptions and links.
+- Avoid 'you' when writing. For example, prefer "This law suggests refactoring should be avoided when..." rather than "you should avoid refactoring when...". This keeps the style slightly more formal and avoids seeming like advocation of a law.
+
+An example law is shown below, which covers most of the key points:
+
+---
+
+### Example Law: The Law of Leaky Abstractions
+
+[The Law of Leaky Abstractions on Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/)
+
+> All non-trivial abstractions, to some degree, are leaky.
+>
+> (Joel Spolsky)
+
+This law states that abstractions, which are generally used in computing to simplify working with complicated systems, will in certain situations 'leak' elements of the underlying system, this making the abstraction behave in an unexpected way.
+
+An example might be loading a file and reading its contents. The file system APIs are an _abstraction_ of the lower level kernel systems, which are themselves an abstraction over the physical processes relating to changing data on a magnetic platter (or flash memory for an SSD). In most cases, the abstraction of treating a file like a stream of binary data will work. However, for a magnetic drive, reading data sequentially will be *significantly* faster than random access (due to increased overhead of page faults), but for an SSD drive, this overhead will not be present. Underlying details will need to be understood to deal with this case (for example, database index files are structured to reduce the overhead of random access), the abstraction 'leaks' implementation details the developer may need to be aware of.
+
+The example above can become more complex when _more_ abstractions are introduced. The Linux operating system allows files to be accessed over a network, but represented locally as 'normal' files. This abstraction will 'leak' if there are network failures. If a developer treats these files as 'normal' files, without considering the fact that they may be subject to network latency and failures, the solutions will be buggy.
+
+The article describing the law suggests that an over-reliance on abstractions, combined with a poor understanding of the underlying processes, actually makes dealing with the problem at hand _more_ complex in some cases.
+
+See also:
+
+- [Hyrum's Law](#hyrums-law-the-law-of-implicit-interfaces)
+
+Real-world examples:
+
+- [Photoshop Slow Startup](https://forums.adobe.com/thread/376152) - an issue I encountered in the past. Photoshop would be slow to startup, sometimes taking minutes. It seems the issue was that on startup it reads some information about the current default printer. However, if that printer is actually a network printer, this could take an extremely long time. The _abstraction_ of a network printer being presented to the system similar to a local printer caused an issue for users in poor connectivity situations.
+
+### Localisation
+
+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!

.github/pull_request_template.md

@@ -0,0 +1,15 @@
+**Pull Request Checklist**
+
+Please double check the items below!
+
+- [ ] I have read the [Contributor Guidelines](./.github/contributing.md).
+- [ ] I have not directly copied text from another location (unless explicitly indicated as a quote) or violated copyright.
+- [ ] I have linked to the original Law.
+- [ ] I have quote the law (if possible) and the author's name (if possible).
+- [ ] I am happy to have my changes merged, so that I appear as a contributor, but also the text altered if required to keep the language consistent in the project.
+
+And don't forget:
+
+- I can handle the table of contents, feel free to leave it out.
+- Check to see if other laws should link back to the law you have added.
+- Include your **Twitter Handle** if you want me to include you when tweeting this update!

.gitignore

@@ -0,0 +1 @@
+.DS_Store

LICENSE

@@ -1,21 +1,173 @@
-MIT License
+Copyright (c) Dave Kerr 2019
 
-Copyright (c) 2018 Dave Kerr
+# Attribution-ShareAlike 4.0 International
 
-Permission is hereby granted, free of charge, to any person obtaining a copy
+Creative Commons Corporation (“Creative Commons”) is not a law firm and does not provide legal services or legal advice. Distribution of Creative Commons public licenses does not create a lawyer-client or other relationship. Creative Commons makes its licenses and related information available on an “as-is” basis. Creative Commons gives no warranties regarding its licenses, any material licensed under their terms and conditions, or any related information. Creative Commons disclaims all liability for damages resulting from their use to the fullest extent possible.
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
 
-The above copyright notice and this permission notice shall be included in all
+### Using Creative Commons Public Licenses
-copies or substantial portions of the Software.
 
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+Creative Commons public licenses provide a standard set of terms and conditions that creators and other rights holders may use to share original works of authorship and other material subject to copyright and certain other rights specified in the public license below. The following considerations are for informational purposes only, are not exhaustive, and do not form part of our licenses.
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+* __Considerations for licensors:__ Our public licenses are intended for use by those authorized to give the public permission to use material in ways otherwise restricted by copyright and certain other rights. Our licenses are irrevocable. Licensors should read and understand the terms and conditions of the license they choose before applying it. Licensors should also secure all rights necessary before applying our licenses so that the public can reuse the material as expected. Licensors should clearly mark any material not subject to the license. This includes other CC-licensed material, or material used under an exception or limitation to copyright. [More considerations for licensors](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensors).
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+* __Considerations for the public:__ By using one of our public licenses, a licensor grants the public permission to use the licensed material under specified terms and conditions. If the licensor’s permission is not necessary for any reason–for example, because of any applicable exception or limitation to copyright–then that use is not regulated by the license. Our licenses grant only permissions under copyright and certain other rights that a licensor has authority to grant. Use of the licensed material may still be restricted for other reasons, including because others have copyright or other rights in the material. A licensor may make special requests, such as asking that all changes be marked or described. Although not required by our licenses, you are encouraged to respect those requests where reasonable. [More considerations for the public](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensees).
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+
-SOFTWARE.
+## Creative Commons Attribution-ShareAlike 4.0 International Public License
+
+By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution-ShareAlike 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions.
+
+### Section 1 – Definitions.
+
+a. __Adapted Material__ means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image.
+
+b. __Adapter's License__ means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License.
+
+c. __BY-SA Compatible License__ means a license listed at [creativecommons.org/compatiblelicenses](http://creativecommons.org/compatiblelicenses), approved by Creative Commons as essentially the equivalent of this Public License.
+
+d. __Copyright and Similar Rights__ means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights.
+
+e. __Effective Technological Measures__ means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements.
+
+f. __Exceptions and Limitations__ means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material.
+
+g. __License Elements__ means the license attributes listed in the name of a Creative Commons Public License. The License Elements of this Public License are Attribution and ShareAlike.
+
+h. __Licensed Material__ means the artistic or literary work, database, or other material to which the Licensor applied this Public License.
+
+i. __Licensed Rights__ means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license.
+
+j. __Licensor__ means the individual(s) or entity(ies) granting rights under this Public License.
+
+k. __Share__ means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them.
+
+l. __Sui Generis Database Rights__ means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world.
+
+m. __You__ means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning.
+
+### Section 2 – Scope.
+
+a. ___License grant.___
+
+   1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to:
+
+       A. reproduce and Share the Licensed Material, in whole or in part; and
+
+       B. produce, reproduce, and Share Adapted Material.
+
+   2. __Exceptions and Limitations.__ For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions.
+
+   3. __Term.__ The term of this Public License is specified in Section 6(a).
+
+   4. __Media and formats; technical modifications allowed.__ The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material.
+
+   5. __Downstream recipients.__
+
+       A. __Offer from the Licensor – Licensed Material.__ Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License.
+
+       B. __Additional offer from the Licensor – Adapted Material.__ Every recipient of Adapted Material from You automatically receives an offer from the Licensor to exercise the Licensed Rights in the Adapted Material under the conditions of the Adapter’s License You apply.
+
+       C. __No downstream restrictions.__ You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material.
+
+   6. __No endorsement.__ Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i).
+
+b. ___Other rights.___
+
+   1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise.
+
+   2. Patent and trademark rights are not licensed under this Public License.
+
+   3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties.
+
+### Section 3 – License Conditions.
+
+Your exercise of the Licensed Rights is expressly made subject to the following conditions.
+
+a. ___Attribution.___
+
+   1. If You Share the Licensed Material (including in modified form), You must:
+
+       A. retain the following if it is supplied by the Licensor with the Licensed Material:
+
+         i. identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated);
+
+         ii. a copyright notice;
+
+         iii. a notice that refers to this Public License;
+
+         iv. a notice that refers to the disclaimer of warranties;
+
+         v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable;
+
+       B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and
+
+       C. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License.
+
+   2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information.
+
+   3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable.
+
+b. ___ShareAlike.___
+
+In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply.
+
+1. The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-SA Compatible License.
+
+2. You must include the text of, or the URI or hyperlink to, the Adapter's License You apply. You may satisfy this condition in any reasonable manner based on the medium, means, and context in which You Share Adapted Material.
+
+3. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, Adapted Material that restrict exercise of the rights granted under the Adapter's License You apply.
+
+### Section 4 – Sui Generis Database Rights.
+
+Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material:
+
+a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database;
+
+b. if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material, including for purposes of Section 3(b); and
+
+c. You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database.
+
+For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights.
+
+### Section 5 – Disclaimer of Warranties and Limitation of Liability.
+
+a. __Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You.__
+
+b. __To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You.__
+
+c. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability.
+
+### Section 6 – Term and Termination.
+
+a. This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically.
+
+b. Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates:
+
+   1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or
+
+   2. upon express reinstatement by the Licensor.
+
+   For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License.
+
+c. For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License.
+
+d. Sections 1, 5, 6, 7, and 8 survive termination of this Public License.
+
+### Section 7 – Other Terms and Conditions.
+
+a. The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed.
+
+b. Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License.
+
+### Section 8 – Interpretation.
+
+a. For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License.
+
+b. To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions.
+
+c. No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor.
+
+d. Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority.
+
+> Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the “Licensor.” The text of the Creative Commons public licenses is dedicated to the public domain under the [CC0 Public Domain Dedication](https://creativecommons.org/publicdomain/zero/1.0/legalcode). Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at [creativecommons.org/policies](http://creativecommons.org/policies), Creative Commons does not authorize the use of the trademark “Creative Commons” or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses.
+>
+> Creative Commons may be contacted at creativecommons.org.

README.md

@@ -1,17 +1,69 @@
-# hacker-laws 
+# 💻📖 hacker-laws
-Laws, Theories, Patterns and Ideas that all developers should know about!
+
+Laws, Theories, Principles and Patterns that developers will find useful.
+
+- 🇨🇳 [中文 / Chinese Version](https://github.com/nusr/hacker-laws-zh) - thanks [Steve Xu](https://github.com/nusr)!
+- 🇮🇹 [Traduzione in Italiano](https://github.com/csparpa/hacker-laws-it) - grazie [Claudio Sparpaglione](https://github.com/csparpa)!
+- 🇰🇷 [한국어 / Korean Version](https://github.com/codeanddonuts/hacker-laws-kr) - thanks [Doughnut](https://github.com/codeanddonuts)!
+- 🇷🇺 [Русская версия / Russian Version](https://github.com/solarrust/hacker-laws) - thanks [Alena Batitskaya](https://github.com/solarrust)!
+- 🇹🇷 [Türkçe / Turkish Version](https://github.com/umutphp/hacker-laws-tr) - thanks [Umut Işık](https://github.com/umutphp)
+- 🇧🇷 [Brasileiro / Brazilian Version](./translations/pt-BR.md) - thanks [Leonardo Costa](https://github.com/LeoFC97)
+- 🇪🇸 [Castellano / Spanish Version](./translations/es-ES.md) - thanks [Manuel Rubio](https://github.com/manuel-rubio)
+
+Like this project? Please considering [Sponsoring Me](https://github.com/sponsors/dwmkerr)!
+
+---
 
 <!-- vim-markdown-toc GFM -->
 
 * [Introduction](#introduction)
-* [The Laws](#the-laws)
+* [Laws](#laws)
-    * [⭐⭐ Conway's Law](#-conways-law)
+    * [Amdahl's Law](#amdahls-law)
-    * [⭐ Hofstadter's Law](#-hofstadters-law)
+    * [The Broken Windows Theory](#the-broken-windows-theory)
-    * [⭐⭐ The Law of Conservation of Complexity (Tesler's Law)](#-the-law-of-conservation-of-complexity-teslers-law)
+    * [Brooks' Law](#brooks-law)
-    * [⭐The Law of Triviality](#the-law-of-triviality)
+    * [Conway's Law](#conways-law)
-    * [⭐⭐ The Robustness Principle (Postel's Law)](#-the-robustness-principle-postels-law)
+    * [Cunningham's Law](#cunninghams-law)
-    * [⭐⭐⭐ The Unix Philosophy](#-the-unix-philosophy)
+    * [Dunbar's Number](#dunbars-number)
-    * [⭐The Spotify Model](#the-spotify-model)
+    * [Gall's Law](#galls-law)
+    * [Goodhart's Law](#goodharts-law)
+    * [Hanlon's Razor](#hanlons-razor)
+    * [Hofstadter's Law](#hofstadters-law)
+    * [Hutber's Law](#hutbers-law)
+    * [The Hype Cycle & Amara's Law](#the-hype-cycle--amaras-law)
+    * [Hyrum's Law (The Law of Implicit Interfaces)](#hyrums-law-the-law-of-implicit-interfaces)
+    * [Metcalfe's Law](#metcalfes-law)
+    * [Moore's Law](#moores-law)
+    * [Murphy's Law / Sod's Law](#murphys-law--sods-law)
+    * [Occam's Razor](#occams-razor)
+    * [Parkinson's Law](#parkinsons-law)
+    * [Premature Optimization Effect](#premature-optimization-effect)
+    * [Putt's Law](#putts-law)
+    * [Reed's Law](#reeds-law)
+    * [The Law of Conservation of Complexity (Tesler's Law)](#the-law-of-conservation-of-complexity-teslers-law)
+    * [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
+    * [The Law of Triviality](#the-law-of-triviality)
+    * [The Unix Philosophy](#the-unix-philosophy)
+    * [The Spotify Model](#the-spotify-model)
+    * [Wadler's Law](#wadlers-law)
+    * [Wheaton's Law](#wheatons-law)
+* [Principles](#principles)
+    * [The Dilbert Principle](#the-dilbert-principle)
+    * [The Pareto Principle (The 80/20 Rule)](#the-pareto-principle-the-8020-rule)
+    * [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)
+* [Reading List](#reading-list)
+* [Contributing](#contributing)
+* [TODO](#todo)
 
 <!-- vim-markdown-toc -->
 
@@ -19,32 +71,334 @@ Laws, Theories, Patterns and Ideas that all developers should know about!
 
 There are lots of laws which people discuss when talking about development. This repository is a reference and overview of some of the most common ones. Please share and submit PRs!
 
-I have tried to use a star rating for how 'important' a law is. The more stars, the more likely you are to hear the law referred to, and therefore the more potentially useful it is to know about it. Of course this is highly subjective, I am open to other suggestions.
-
 ❗: 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.
 
-## The Laws
+## Laws
 
 And here we go!
 
+### Amdahl's Law
 
-### ⭐⭐ Conway's Law
+[Amdahl's Law on Wikipedia](https://en.wikipedia.org/wiki/Amdahl%27s_law)
+
+> Amdahl's Law is a formula which shows the _potential speedup_ of a computational task which can be achieved by increasing the resources of a system. Normally used in parallel computing, it can predict the actual benefit of increasing the number of processors, which is limited by the parallelisability of the program.
+
+Best illustrated with an example. If a program is made up of two parts, part A, which must be executed by a single processor, and part B, which can be parallelised, then we see that adding multiple processors to the system executing the program can only have a limited benefit. It can potentially greatly improve the speed of part B - but the speed of part A will remain unchanged.
+
+The diagram below shows some examples of potential improvements in speed:
+
+<img width="480px" alt="Diagram: Amdahl's Law" src="./images/amdahls_law.png" />
+
+*(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.
+
+As [Moore's Law](#moores-law) slows, and the acceleration of individual processor speed slows, parallelisation is key to improving performance. Graphics programming is an excellent example - with modern Shader based computing, individual pixels or fragments can be rendered in parallel - this is why modern graphics cards often have many thousands of processing cores (GPUs or Shader Units).
+
+See also:
+
+- [Brooks' Law](#brooks-law)
+- [Moore's Law](#moores-law)
+
+### The Broken Windows Theory
+
+[The Broken Windows Theory on Wikipedia](https://en.wikipedia.org/wiki/Broken_windows_theory)
+
+The Broken Windows Theory suggests that visible signs of crime (or lack of care of an environment) lead to further and more serious crimes (or further deterioration of the environment).
+
+This theory has been applied to software development, suggesting that poor quality code (or [Technical Debt](#TODO)) can lead to a perception that efforts to improve quality may be ignored or undervalued, thus leading to further poor quality code. This effect cascades leading to a great decrease in quality over time.
+
+See also:
+
+- [Technical Debt](#TODO)
+
+Examples:
+
+- [The Pragmatic Programming: Software Entropy](https://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/)
+
+### Brooks' Law
+
+[Brooks' Law on Wikipedia](https://en.wikipedia.org/wiki/Brooks%27s_law)
+
+> Adding human resources to a late software development project makes it later.
+
+This law suggests that in many cases, attempting to accelerate the delivery of a project which is already late, by adding more people, will make the delivery even later. Brooks is clear that this is an over-simplification, however, the general reasoning is that given the ramp up time of new resources and the communication overheads, in the immediate short-term velocity decreases. Also, many tasks may not be divisible, i.e. easily distributed between more resources, meaning the potential velocity increase is also lower.
+
+The common phrase in delivery "Nine women can't make a baby in one month" relates to Brooks' Law, in particular, the fact that some kinds of work are not divisible or parallelisable.
+
+This is a central theme of the book '[The Mythical Man Month](#reading-list)'.
+
+See also:
+
+- [Death March](#todo)
+- [Reading List: The Mythical Man Month](#reading-list)
+
+### 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.
 
-See also: 'The Spotify Model'.
+See also:
 
-### ⭐ Hofstadter's Law
+- [The Spotify Model](#the-spotify-model)
+
+### Cunningham's Law
+
+[Cunningham's Law on Wikipedia](https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham's_Law)
+
+> The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer.
+
+According to Steven McGeady, Ward Cunningham advised him in the early 1980s: "The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer." McGeady dubbed this Cunningham's law, though Cunningham denies ownership calling it a "misquote." Although originally referring to interactions on Usenet, the law has been used to describe how other online communities work (e.g., Wikipedia, Reddit, Twitter, Facebook).
+
+See also:
+
+- [XKCD 386: "Duty Calls"](https://xkcd.com/386/)
+
+### Dunbar's Number
+
+[Dunbar's Number on Wikipedia](https://en.wikipedia.org/wiki/Dunbar%27s_number)
+
+"Dunbar's number is a suggested cognitive limit to the number of people with whom one can maintain stable social relationships— relationships in which an individual knows who each person is and how each person relates to every other person." There is some disagreement to the exact number. "... [Dunbar] proposed that humans can comfortably maintain only 150 stable relationships." He put the number into a more social context, "the number of people you would not feel embarrassed about joining uninvited for a drink if you happened to bump into them in a bar." Estimates for the number generally lay between 100 and 250.
+
+Like stable relationships between individuals, a developer's relationship with a codebase takes effort to maintain. When faced with large complicated projects, or ownership of many projects we lean on convention, policy, and modeled procedure to scale. Dunbar's number is not only important to keep in mind as an office grows, but also when setting the scope for team efforts or deciding when a system should invest in tooling to assist in modeling and automating logistical overhead. Putting the number into an engineering context, it is the number of projects (or normalized complexity of a single project) for which you would feel confident in joining an on-call rotation to support.
+
+See also:
+
+- [Conway's Law](#conways-law)
+
+### Gall's Law
+
+[Gall's Law on Wikipedia](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law)
+
+> A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
+>
+> ([John Gall](https://en.wikipedia.org/wiki/John_Gall_(author)))
+
+Gall's Law implies that attempts to _design_ highly complex systems are likely to fail. Highly complex systems are rarely built in one go, but evolve instead from more simple systems.
+
+The classic example is the world-wide-web. In it's current state, it is a highly complex system. However, it was defined initially as a simple way to share content between academic institutions. It was very successful in meeting these goals and evolved to become more complex over time.
+
+See also:
+
+- [KISS (Keep It Simple, Stupid)](#the-kiss-principle)
+
+### Goodhart's Law
+
+[The Goodhart's Law on Wikipedia](https://en.wikipedia.org/wiki/Goodhart's_law)
+
+> Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.
+>
+> _Charles Goodhart_
+
+Also commonly referenced as:
+
+> When a measure becomes a target, it ceases to be a good measure.
+>
+> _Marilyn Strathern_
+
+The law states that the measure-driven optimizations could lead to devaluation of the measurement outcome itself. Overly selective set of measures ([KPIs](https://en.wikipedia.org/wiki/Performance_indicator)) blindly applied to a process results in distorted effect. People tend to optimize locally by "gaming" the system in order to satisfy particular metrics instead of paying attention to holistic outcome of their actions.
+
+Real-world examples:
+- Assert-free tests satisfy the code coverage expectation, despite the metric intent was to create well-tested software.
+- Developer performance score indicated by the number of lines committed leads to unjustifiably bloated codebase.
+
+See also:
+- [Goodhart’s Law: How Measuring The Wrong Things Drive Immoral Behaviour](https://coffeeandjunk.com/goodharts-campbells-law/)
+- [Dilbert on bug-free software](https://dilbert.com/strip/1995-11-13)
+
+### Hanlon's Razor
+
+[Hanlon's Razor on Wikipedia](https://en.wikipedia.org/wiki/Hanlon%27s_razor)
+
+> Never attribute to malice that which is adequately explained by stupidity.
+>
+> Robert J. Hanlon
+
+This principle suggests that actions resulting in a negative outcome were not a result of ill will. Instead the negative outcome is more likely attributed to those actions and/or the impact being not fully understood.
+
+### Hofstadter's Law
 
 [Hofstadter's Law on Wikipedia](https://en.wikipedia.org/wiki/Hofstadter%27s_law)
 
 > It always takes longer than you expect, even when you take into account Hofstadter's Law.
+>
+> (Douglas Hofstadter)
 
 You might hear this law referred to when looking at estimates for how long something will take. It seems a truism in software development that we tend to not be very good at accurately estimating how long something will take to deliver.
 
-### ⭐⭐ The Law of Conservation of Complexity (Tesler's Law)
+This is from the book '[Gödel, Escher, Bach: An Eternal Golden Braid](#reading-list)'.
+
+See also:
+
+- [Reading List: Gödel, Escher, Bach: An Eternal Golden Braid](#reading-list)
+
+### Hutber's Law
+
+[Hutber's Law on Wikipedia](https://en.wikipedia.org/wiki/Hutber%27s_law)
+
+> Improvement means deterioration.
+>
+> ([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber))
+
+This law suggests that improvements to a system will lead to deterioration in other parts, or it will hide other deterioration, leading overall to a degradation from the current state of the system.
+
+For example, a decrease in response latency for a particular end-point could cause increased throughput and capacity issues further along in a request flow, affecting an entirely different sub-system.
+
+### The Hype Cycle & Amara's Law
+
+[The Hype Cycle on Wikipedia](https://en.wikipedia.org/wiki/Hype_cycle)
+
+> We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run.
+>
+> (Roy Amara)
+
+The Hype Cycle is a visual representation of the excitement and development of technology over time, originally produced by Gartner. It is best shown with a visual:
+
+![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".
+
+### Hyrum's Law (The Law of Implicit Interfaces)
+
+[Hyrum's Law Online](http://www.hyrumslaw.com/)
+
+> With a sufficient number of users of an API,
+> it does not matter what you promise in the contract:
+> all observable behaviours of your system
+> will be depended on by somebody.
+>
+> (Hyrum Wright)
+
+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/)
+
+
+### Metcalfe's Law
+
+[Metcalfe's Law on Wikipedia](https://en.wikipedia.org/wiki/Metcalfe's_law)
+
+> In network theory, the value of a system grows as approximately the square of the number of users of the system.
+
+This law is based on the number of possible pairwise connections within a system and is closely related to [Reed's Law](#reeds-law). Odlyzko and others have argued that both Reed's Law and Metcalfe's Law overstate the value of the system by not accounting for the limits of human cognition on network effects; see [Dunbar's Number](#dunbars-number).
+
+See also:
+- [Reed's Law](#reeds-law)
+- [Dunbar's Number](#dunbars-number)
+
+### Moore's Law
+
+[Moore's Law on Wikipedia](https://en.wikipedia.org/wiki/Moore%27s_law)
+
+> The number of transistors in an integrated circuit doubles approximately every two years.
+
+Often used to illustrate the sheer speed at which semiconductor and chip technology has improved, Moore's prediction has proven to be highly accurate over from the 1970s to the late 2000s. In more recent years, the trend has changed slightly, partly due to [physical limitations on the degree to which components can be miniaturised](https://en.wikipedia.org/wiki/Quantum_tunnelling). However, advancements in parallelisation, and potentially revolutionary changes in semiconductor technology and quantum computing may mean that Moore's Law could continue to hold true for decades to come.
+
+### Murphy's Law / Sod's Law
+
+[Murphy's Law on Wikipedia](https://en.wikipedia.org/wiki/Murphy%27s_law)
+
+> Anything that can go wrong will go wrong.
+
+Related to [Edward A. Murphy, Jr](https://en.wikipedia.org/wiki/Edward_A._Murphy_Jr.) _Murphy's Law_ states that if a thing can go wrong, it will go wrong.
+
+This is a common adage among developers. Sometimes the unexpected happens when developing, testing or even in production. This can also be related to the (more common in British English) _Sod's Law_:
+
+> If something can go wrong, it will, at the worst possible time.
+
+These 'laws' are generally used in a comic sense. However, phenomena such as [_Confirmation Bias_](#TODO) and [_Selection Bias_](#TODO) can lead people to perhaps over-emphasise these laws (the majority of times when things work, they go unnoticed, failures however are more noticeable and draw more discussion).
+
+See Also:
+
+- [Confirmation Bias](#TODO)
+- [Selection Bias](#TODO)
+
+### Occam's Razor
+
+[Occam's Razor on Wikipedia](https://en.wikipedia.org/wiki/Occam's_razor)
+
+> Entities should not be multiplied without necessity.
+>
+> William of Ockham
+
+Occam's razor says that among several possible solutions, the most likely solution is the one with the least number of concepts and assumptions. This solution is the simplest and solves only the given problem, without introducing accidental complexity and possible negative consequences.
+
+See also:
+
+- [YAGNI](#yagni)
+- [No Silver Bullet: Accidental Complexity and Essential Complexity](https://en.wikipedia.org/wiki/No_Silver_Bullet)
+
+Example:
+
+- [Lean Software Development: Eliminate Waste](https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste)
+
+### Parkinson's Law
+
+[Parkinson's Law on Wikipedia](https://en.wikipedia.org/wiki/Parkinson%27s_law)
+
+> Work expands so as to fill the time available for its completion.
+
+In its original context, this Law was based on studies of bureaucracies. It may be pessimistically applied to software development initiatives, the theory being that teams will be inefficient until deadlines near, then rush to complete work by the deadline, thus making the actual deadline somewhat arbitrary.
+
+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:
+
+- [Hofstadter's Law](#hofstadters-law)
+
+### Premature Optimization Effect
+
+[Premature Optimization on WikiWikiWeb](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.
+
+### Putt's Law
+
+[Putt's Law on Wikipedia](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat)
+
+> Technology is dominated by two types of people, those who understand what they do not manage and those who manage what they do not understand.
+
+Putt's Law is often followed by Putt's Corollary:
+
+> Every technical hierarchy, in time, develops a competence inversion.
+
+These statements suggest that due to various selection criteria and trends in how groups organise, there will be a number of skilled people at working levels of a technical organisations, and a number of people in managerial roles who are not aware of the complexities and challenges of the work they are managing. This can be due to phenomena such as [The Peter Principle](#the-peter-principle) or [The Dilbert Principle](#the-dilbert-principle).
+
+However, it should be stressed that Laws such as this are vast generalisations and may apply to _some_ types of organisations, and not apply to others.
+
+See also:
+
+- [The Peter Principle](#the-peter-principle)
+- [The Dilbert Principle](#the-dilbert-principle)
+
+
+### Reed's Law
+
+[Reed's Law on Wikipedia](https://en.wikipedia.org/wiki/Reed's_law)
+
+> The utility of large networks, particularly social networks, scales exponentially with the size of the network.
+
+This law is based on graph theory, where the utility scales as the number of possible sub-groups, which is faster than the number of participants or the number of possible pairwise connections. Odlyzko and others have argued that Reed's Law overstates the utility of the system by not accounting for the limits of human cognition on network effects; see [Dunbar's Number](#dunbars-number).
+
+See also:
+- [Metcalfe's Law](#metcalfes-law)
+- [Dunbar's Number](#dunbars-number)
+
+### The 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)
 
@@ -54,7 +408,31 @@ 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 Triviality
+### The Law of Leaky Abstractions
+
+[The Law of Leaky Abstractions on Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/)
+
+> All non-trivial abstractions, to some degree, are leaky.
+>
+> ([Joel Spolsky](https://twitter.com/spolsky))
+
+This law states that abstractions, which are generally used in computing to simplify working with complicated systems, will in certain situations 'leak' elements of the underlying system, this making the abstraction behave in an unexpected way.
+
+An example might be loading a file and reading its contents. The file system APIs are an _abstraction_ of the lower level kernel systems, which are themselves an abstraction over the physical processes relating to changing data on a magnetic platter (or flash memory for an SSD). In most cases, the abstraction of treating a file like a stream of binary data will work. However, for a magnetic drive, reading data sequentially will be *significantly* faster than random access (due to increased overhead of page faults), but for an SSD drive, this overhead will not be present. Underlying details will need to be understood to deal with this case (for example, database index files are structured to reduce the overhead of random access), the abstraction 'leaks' implementation details the developer may need to be aware of.
+
+The example above can become more complex when _more_ abstractions are introduced. The Linux operating system allows files to be accessed over a network but represented locally as 'normal' files. This abstraction will 'leak' if there are network failures. If a developer treats these files as 'normal' files, without considering the fact that they may be subject to network latency and failures, the solutions will be buggy.
+
+The article describing the law suggests that an over-reliance on abstractions, combined with a poor understanding of the underlying processes, actually makes dealing with the problem at hand _more_ complex in some cases.
+
+See also:
+
+- [Hyrum's Law](#hyrums-law-the-law-of-implicit-interfaces)
+
+Real-world examples:
+
+- [Photoshop Slow Startup](https://forums.adobe.com/thread/376152) - an issue I encountered in the past. Photoshop would be slow to startup, sometimes taking minutes. It seems the issue was that on startup it reads some information about the current default printer. However, if that printer is actually a network printer, this could take an extremely long time. The _abstraction_ of a network printer being presented to the system similar to a local printer caused an issue for users in poor connectivity situations.
+
+### The Law of Triviality
 
 [The Law of Triviality on Wikipedia](https://en.wikipedia.org/wiki/Law_of_triviality)
 
@@ -62,9 +440,114 @@ This law suggests that groups will give far more time and attention to trivial o
 
 The common fictional example used is that of a committee approving plans for nuclear power plant, who spend the majority of their time discussing the structure of the bike shed, rather than the far more important design for the power plant itself. It can be difficult to give valuable input on discussions about very large, complex topics without a high degree of subject matter expertise or preparation. However, people want to be seen to be contributing valuable input. Hence a tendency to focus too much time on small details, which can be reasoned about easily, but are not necessarily of particular importance.
 
-The fictional example above led to the usage of the term 'Bike Shedding' as an expression for wasting time on trivial details.
+The fictional example above led to the usage of the term 'Bike Shedding' as an expression for wasting time on trivial details. An alternative term is 'Yak Shaving'.
 
-### ⭐⭐ The Robustness Principle (Postel's Law)
+### The Unix Philosophy
+
+[The Unix Philosophy on Wikipedia](https://en.wikipedia.org/wiki/Unix_philosophy)
+
+The Unix Philosophy is that software components should be small, and focused on doing one specific thing well. This can make it easier to build systems by composing together small, simple, well-defined units, rather than using large, complex, multi-purpose programs.
+
+Modern practices like 'Microservice Architecture' can be thought of as an application of this law, where services are small, focused and do one specific thing, allowing complex behaviour to be composed of simple building blocks.
+
+### The Spotify Model
+
+[The Spotify Model on Spotify Labs](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/)
+
+The Spotify Model is an approach to team and organisation structure which has been popularised by 'Spotify'. In this model, teams are organised around features, rather than technologies.
+
+The Spotify Model also popularises the concepts of Tribes, Guilds, Chapters, which are other components of their organisation structure.
+
+### Wadler's Law
+
+[Wadler's Law on wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law)
+
+> In any language design, the total time spent discussing a feature in this list is proportional to two raised to the power of its position.
+>
+> 0. Semantics
+> 1. Syntax
+> 2. Lexical syntax
+> 3. Lexical syntax of comments
+>
+> (In short, for every hour spent on semantics, 8 hours will be spent on the syntax of comments).
+
+Similar to [The Law of Triviality](#the-law-of-triviality), Wadler's Law states what when designing a language, the amount of time spent on language structures is disproportionately high in comparison to the importance of those features.
+
+See also:
+
+- [The Law of Triviality](#the-law-of-triviality)
+
+### Wheaton's Law
+
+[The Link](http://www.wheatonslaw.com/)
+
+[The Official Day](https://dontbeadickday.com/)
+
+> Don't be a dick.
+>
+> _Wil Wheaton_
+
+Coined by Wil Wheaton (Star Trek: The Next Generation, The Big Bang Theory), this simple, concise, and powerful law aims for an increase in harmony and respect within a professional organization. It can be applied when speaking with coworkers, performing code reviews, countering other points of view, critiquing, and in general, most professional interactions humans have with each other.
+
+## Principles
+
+Principles are generally more likely to be guidelines relating to design.
+
+### The Dilbert Principle
+
+[The Dilbert Principle on Wikipedia](https://en.wikipedia.org/wiki/Dilbert_principle)
+
+> Companies tend to systematically promote incompetent employees to management to get them out of the workflow.
+>
+> _Scott Adams_
+
+A management concept developed by Scott Adams (creator of the Dilbert comic strip), the Dilbert Principle is inspired by [The Peter Principle](#the-peter-principle). Under the Dilbert Principle, employees who were never competent are promoted to management in order to limit the damage they can do. Adams first explained the principle in a 1995 Wall Street Journal article, and expanded upon it in his 1996 business book, [The Dilbert Principle](#reading-list).
+
+See Also:
+
+- [The Peter Principle](#the-peter-principle)
+- [Putt's Law](#putts-law)
+
+### The Pareto Principle (The 80/20 Rule)
+
+[The Pareto Principle on Wikipedia](https://en.wikipedia.org/wiki/Pareto_principle)
+
+> Most things in life are not distributed evenly.
+
+The Pareto Principle suggests that in some cases, the majority of results come from a minority of inputs:
+
+- 80% of a certain piece of software can be written in 20% of the total allocated time (conversely, the hardest 20% of the code takes 80% of the time)
+- 20% of the effort produces 80% of the result
+- 20% of the work creates 80% of the revenue
+- 20% of the bugs cause 80% of the crashes
+- 20% of the features cause 80% of the usage
+
+In the 1940s American-Romanian engineer Dr. Joseph Juran, who is widely credited with being the father of quality control, [began to apply the Pareto principle to quality issues](https://en.wikipedia.org/wiki/Joseph_M._Juran).
+
+This principle is also known as: The 80/20 Rule, The Law of the Vital Few and The Principle of Factor Sparsity.
+
+Real-world examples:
+
+- In 2002 Microsoft reported that by fixing the top 20% of the most-reported bugs, 80% of the related errors and crashes in windows and office would become eliminated ([Reference](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)).
+
+### The Peter Principle
+
+[The Peter Principle on Wikipedia](https://en.wikipedia.org/wiki/Peter_principle)
+
+> People in a hierarchy tend to rise to their "level of incompetence".
+>
+> _Laurence J. Peter_
+
+A management concept developed by Laurence J. Peter, the Peter Principle observes that people who are good at their jobs are promoted, until they reach a level where they are no longer successful (their "level of incompetence". At this point, as they are more senior, they are less likely to be removed from the organisation (unless they perform spectacularly badly) and will continue to reside in a role which they have few intrinsic skills at, as their original skills which made them successful are not necessarily the skills required for their new jobs.
+
+This is of particular interest to engineers - who initial start out in deeply technical roles, but often have a career path which leads to _managing_ other engineers - which requires a fundamentally different skills-set.
+
+See Also:
+
+- [The Dilbert Principle](#the-dilbert-principle)
+- [Putt's Law](#putts-law)
+
+### The Robustness Principle (Postel's Law)
 
 [The Robustness Principle on Wikipedia](https://en.wikipedia.org/wiki/Robustness_principle)
 
@@ -74,18 +557,198 @@ Often applied in server application development, this principle states that what
 
 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 Unix Philosophy
+### SOLID
 
-[The Unix Philosophy on Wikipedia](https://en.wikipedia.org/wiki/Unix_philosophy)
+This is an acronym, which refers to:
 
-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.
+* 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)
 
-Modern practices like 'Microservice Architecture' can be thought of as an application of this law, where services are small, focused and do one specific thing, allowing complex behaviour to be composed from simple building blocks.
+These are key principles in [Object-Oriented Programming](#todo). Design principles such as these should be able to aid developers build more maintainable systems.
 
-### ⭐The Spotify Model
+### The Single Responsibility Principle
 
-[The Spotify Model on Spotify Labs](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/)
+[The Single Responsibility Principle on Wikipedia](https://en.wikipedia.org/wiki/Single_responsibility_principle)
 
-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.
+> Every module or class should have a single responsibility only.
 
-The Spotify Model also popularises the concepts of Tribes, Guilds, Chapters, which are other components of their organisation structure.
+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.
+
+See also:
+
+- [Object-Oriented Programming](#todo)
+- [SOLID](#solid)
+
+### The Open/Closed Principle
+
+[The Open/Closed Principle on Wikipedia](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle)
+
+> Entities should be open for extension and closed for modification.
+
+The second of the '[SOLID](#solid)' principles. This principle states that entities (which could be classes, modules, functions and so on) should be able to have their behaviour _extended_, but that their _existing_ behaviour should not be able to be modified.
+
+As a hypothetical example, imagine a module which is able to turn a Markdown document into HTML. If the module could be extended to handle a newly proposed markdown feature, without modifying the module internals, then it would be open for extension. If the module could _not_ be modified by a consumer so that how existing Markdown features are handled, then it would be _closed_ for modification.
+
+This principle has particular relevance for object-oriented programming, where we may design objects to be easily extended, but would avoid designing objects which can have their existing behaviour changed in unexpected ways.
+
+See also:
+
+- [Object-Oriented Programming](#todo)
+- [SOLID](#solid)
+
+### The Liskov Substitution Principle
+
+[The Liskov Substitution Principle on Wikipedia](https://en.wikipedia.org/wiki/Liskov_substitution_principle)
+
+> It should be possible to replace a type with a subtype, without breaking the system.
+
+The third of the '[SOLID](#solid)' principles. This principle states that if a component relies on a type, then it should be able to use subtypes of that type, without the system failing or having to know the details of what that subtype is.
+
+As an example, imagine we have a method which reads an XML document from a structure which represents a file. If the method uses a base type 'file', then anything which derives from 'file' should be able to be used in the function. If 'file' supports seeking in reverse, and the XML parser uses that function, but the derived type 'network file' fails when reverse seeking is attempted, then the 'network file' would be violating the principle.
+
+This principle has particular relevance for object-oriented programming, where type hierarchies must be modeled carefully to avoid confusing users of a system.
+
+See also:
+
+- [Object-Oriented Programming](#todo)
+- [SOLID](#solid)
+
+### The Interface Segregation Principle
+
+[The Interface Segregation Principle on Wikipedia](https://en.wikipedia.org/wiki/Interface_segregation_principle)
+
+> No client should be forced to depend on methods it does not use.
+
+The fourth of the '[SOLID](#solid)' principles. This principle states that consumers of a component should not depend on functions of that component which it doesn't actually use.
+
+As an example, imagine we have a method which reads an XML document from a structure which represents a file. It only needs to read bytes, move forwards or move backwards in the file. If this method needs to be updated because an unrelated feature of the file structure changes (such as an update to the permissions model used to represent file security), then the principle has been invalidated. It would be better for the file to implement a 'seekable-stream' interface, and for the XML reader to use that.
+
+This principle has particular relevance for object-oriented programming, where interfaces, hierarchies and abstract types are used to [minimise the coupling](#todo) between different components. [Duck typing](#todo) is a methodology which enforces this principle by eliminating explicit interfaces.
+
+See also:
+
+- [Object-Oriented Programming](#todo)
+- [SOLID](#solid)
+- [Duck Typing](#todo)
+- [Decoupling](#todo)
+
+### The Dependency Inversion Principle
+
+[The Dependency Inversion Principle on Wikipedia](https://en.wikipedia.org/wiki/Dependency_inversion_principle)
+
+> High-level modules should not be dependent on low-level implementations.
+
+The fifth of the '[SOLID](#solid)' principles. This principle states that higher level orchestrating components should not have to know the details of their dependencies.
+
+As an example, imagine we have a program which read metadata from a website. We would assume that the main component would have to know about a component to download the webpage content, then a component which can read the metadata. If we were to take dependency inversion into account, the main component would depend only on an abstract component which can fetch byte data, and then an abstract component which would be able to read metadata from a byte stream. The main component would not know about TCP/IP, HTTP, HTML, etc.
+
+This principle is complex, as it can seem to 'invert' the expected dependencies of a system (hence the name). In practice, it also means that a separate orchestrating component must ensure the correct implementations of abstract types are used (e.g. in the previous example, _something_ must still provide the metadata reader component a HTTP file downloader and HTML meta tag reader). This then touches on patterns such as [Inversion of Control](#todo) and [Dependency Injection](#todo).
+
+See also:
+
+- [Object-Oriented Programming](#todo)
+- [SOLID](#solid)
+- [Inversion of Control](#todo)
+- [Dependency Injection](#todo)
+
+### The DRY Principle
+
+[The DRY Principle on Wikipedia](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)
+
+> Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
+
+DRY is an acronym for _Don't Repeat Yourself_. This principle aims to help developers reducing the repetition of code and keep the information in a single place and was cited in 1999 by Andrew Hunt and Dave Thomas in the book [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+
+> The opposite of DRY would be _WET_ (Write Everything Twice or We Enjoy Typing).
+
+In practice, if you have the same piece of information in two (or more) different places, you can use DRY to merge them into a single one and reuse it wherever you want/need.
+
+See also:
+
+- [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+
+### The KISS principle
+
+[KISS on Wikipedia](https://en.wikipedia.org/wiki/KISS_principle)
+
+> Keep it simple, stupid
+
+The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided.  Originating in the U.S. Navy in 1960, the phrase has been associated with aircraft engineer Kelly Johnson.
+
+The principle is best exemplified by the story of Johnson handing a team of design engineers a handful of tools, with the challenge that the jet aircraft they were designing must be repairable by an average mechanic in the field under combat conditions with only these tools. Hence, the "stupid" refers to the relationship between the way things break and the sophistication of the tools available to repair them, not the capabilities of the engineers themselves. 
+
+See also:
+
+- [Gall's Law](#galls-law)
+
+### YAGNI
+
+[YAGNI on Wikipedia](https://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it)
+
+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.
+>
+> ([Ron Jeffries](https://twitter.com/RonJeffries)) (XP co-founder and author of the book "Extreme Programming Installed")
+
+This _Extreme Programming_ (XP) principle suggests developers should only implement functionality that is needed for the immediate requirements, and avoid attempts to predict the future by implementing functionality that might be needed later.
+
+Adhering to this principle should reduce the amount of unused code in the codebase, and avoid time and effort being wasted on functionality that brings no value.
+
+See also:
+
+- [Reading List: Extreme Programming Installed](#reading-list)
+
+### The Fallacies of Distributed Computing
+
+[The Fallacies of Distributed Computing on Wikipedia](https://en.wikipedia.org/wiki/You_aren%https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing)
+
+Also known as _Fallacies of Networked Computing_, the Fallacies are a list of conjectures (or beliefs) about distributed computing, which can lead to failures in software development. The assumptions are:
+
+- The network is reliable
+- Latency is zero
+- Bandwidth is infinite
+- The network is secure
+- Topology doesn't change
+- There is one administrator
+- Transport cost is zero
+- The network is homogeneous
+
+The first four items were listed by [Bill Joy](https://en.wikipedia.org/wiki/Bill_Joy) and [Tom Lyon](https://twitter.com/aka_pugs) around 1991 and first classified by [James Gosling](https://en.wikipedia.org/wiki/James_Gosling) as the "Fallacies of Networked Computing". [L. Peter Deutsch](https://en.wikipedia.org/wiki/L._Peter_Deutsch) added the 5th, 6th and 7th fallacies. In the late 90's Gosling added the 8th fallacy.
+
+The group were inspired by what was happening at the time inside [Sun Microsystems](https://en.wikipedia.org/wiki/Sun_Microsystems).
+
+These fallacies should be considered carefully when designing code which is resilient; assuming any of these fallacies can lead to flawed logic which fails to deal with the realities and complexities of distributed systems.
+
+See also:
+
+- [Foraging for the Fallacies of Distributed Computing (Part 1) - Vaidehi Joshi
+ on Medium](https://medium.com/baseds/foraging-for-the-fallacies-of-distributed-computing-part-1-1b35c3b85b53)
+- [Deutsch's Fallacies, 10 Years After](http://java.sys-con.com/node/38665)
+
+## Reading List
+
+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) - 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.
+- [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 Peter Principle - Lawrence J. Peter](https://www.goodreads.com/book/show/890728.The_Peter_Principle) - Another comic look at the challenges of larger organisations and people management, the source of [The Peter Principle](#the-peter-principle).
+
+## Contributing
+
+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.
+
+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.
+
+## 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

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

translations/es-ES.md

@@ -0,0 +1,645 @@
+# 💻📖 hacker-laws
+
+Leyes, Teorías, Principios y Patrones que los desarrolladores encontrarán útiles.
+
+- 🇨🇳 [中文 / Versión China](https://github.com/nusr/hacker-laws-zh) - thanks [Steve Xu](https://github.com/nusr)!
+- 🇮🇹 [Traduzione in Italiano](https://github.com/csparpa/hacker-laws-it) - grazie [Claudio Sparpaglione](https://github.com/csparpa)!
+- 🇰🇷 [한국어 / Versión Koreana](https://github.com/codeanddonuts/hacker-laws-kr) - thanks [Doughnut](https://github.com/codeanddonuts)!
+- 🇷🇺 [Русская версия / Versión Rusa](https://github.com/solarrust/hacker-laws) - thanks [Alena Batitskaya](https://github.com/solarrust)!
+- 🇹🇷 [Türkçe / Versión Turca](https://github.com/umutphp/hacker-laws-tr) - thanks [Umut Işık](https://github.com/umutphp)
+- 🇧🇷 [Brasileiro / Versión Brasileña](./translations/pt-BR.md) - thanks [Leonardo Costa](https://github.com/LeoFC97)
+- 🇺🇸 [Original English Version - Versión Original en Inglés](https://github.com/dwmkerr/hacker-laws) - grazie [Dave Kerr](https://github.com/dwmkerr)!
+
+¿Te gusta este proyecto? Por favor, considera [Esponsorizarme](https://github.com/sponsors/dwmkerr)!
+
+---
+
+<!-- vim-markdown-toc GFM -->
+
+* [Introducción](#introduccion)
+* [Leyes](#leyes)
+    * [Ley de Amdahl](#ley-de-amdahl)
+    * [Ley de Brooks](#ley-de-brooks)
+    * [Ley de Conway](#ley-de-conways)
+    * [Ley de Cunningham](#ley-de-cunningham)
+    * [Número de Dunbar](#numero-de-dunbar)
+    * [Ley de Gall](#ley-de-gall)
+    * [Cuchilla de Hanlon](#cuchilla-de-hanlon)
+    * [Ley de Hofstadter](#ley-de-hofstadter)
+    * [Ley de Hutber](#ley-de-hutber)
+    * [El Ciclo de Sobreexpectación y la Ley de Amara](#el-ciclo-de-sobreexpectacion-y-la-ley-de-amara)
+    * [Ley de Hyrum (La Ley de las Interfaces Implícitas)](#ley-de-hyrum-la-ley-de-las-interfaces-implicitas)
+    * [Ley de Metcalfe](#ley-de-metcalfe)
+    * [Ley de Moore](#ley-de-moore)
+    * [Ley de Murphy / Ley de Sod](#ley-de-murphy--ley-de-sod)
+    * [Ley de Parkinson](#ley-de-parkinson)
+    * [Efecto de Optimización Prematura](#efecto-de-optimizacion-prematura)
+    * [Ley de Putt](#ley-de-putt)
+    * [Ley de Reed](#ley-de-reed)
+    * [Ley de Conservación de Complejidad (Ley de Tesler)](#ley-de-conservacion-de-complejidad-ley-de-tesler)
+    * [Ley de Abstracciones Permeables](#ley-de-abstracciones-permeables)
+    * [Ley de la Trivialidad](#ley-de-la-trivialidad)
+    * [Filosofía Unix](#filosofia-unix)
+    * [El Modelo Spotify](#el-modelo-spotify)
+    * [Ley de Wadler](#ley-de-wadler)
+* [Principios](#principios)
+    * [El Principio de Dilbert](#el-principio-de-dilbert)
+    * [El Principio de Pareto (La Regla 80/20)](#el-principio-de-pareto-la-regla-8020)
+    * [El Principio de Peter](#el-principio-de-peter)
+    * [El Principio de la Robustez (Ley de Postel)](#el-principio-de-la-robustez-ley-de-postel)
+    * [SOLID](#solid)
+    * [El Principio de Única Responsabilidad](#el-principio-de-unica-responsabilidad)
+    * [El Principio Abierto/Cerrado](#el-principio-abierto-cerrado)
+    * [El Principio de Sustitución de Liskov](#el-principio-de-sustitucion-de-liskov)
+    * [El Principio de Segregación de Interfaz](#el-principio-de-segregacion-de-interfaz)
+    * [El Principio de Inversión de Dependencia](#el-principio-de-inversion-de-dependencia)
+    * [El Principio DRY](#el-principio-dry)
+    * [El Principio KISS](#el-principio-kiss)
+    * [YAGNI](#yagni)
+* [Lista de Lectura](#lista-de-lectura)
+* [POR-HACER](#por-hacer)
+
+<!-- vim-markdown-toc -->
+
+## Introducción
+
+Hay montones de leyes que la gente discute cuando habla sobre desarrollo. Este repositorio es una referencia y un resumen de algunos de los más conocidos. Por favor, ¡comparte y sube tus PRs!
+
+❗: Este repositorio contiene una explicación sobre algunas leyes, principios y patrones, pero no _defendemos_ ninguno de ellos. Si estos pueden ser aplicados o no siempre será materia de debate y muy dependiente de en qué estés trabajando.
+
+## Leyes
+
+¡Y aquí vamos!
+
+### Ley de Amdahl
+
+[Ley de Amdahl en Wikipedia](https://es.wikipedia.org/wiki/Ley_de_Amdahl)
+
+> La ley de Amdahl se puede interpretar de manera más técnica, pero en términos simples, significa que es el algoritmo el que decide la mejora de velocidad, no el número de procesadores. Finalmente se llega a un momento que no se puede paralelizar más el algoritmo.
+
+Mejor lo ilustramos con un ejemplo. Si un programa se compone de dos partes, la parte A debe ser ejecutada en un solo procesador y la parte B puede ser paralelizada, entonces vemos que agregamos múltiples procesadores al sistema en ejecución ese programa puede solo tener un beneficio limitado. Este puede potencialmente mejorar mucho la velocidad de la parte B - pero la velocidad de la parte A se mantendrá sin cambios.
+
+El diagrama de abajo muestra algunos ejemplos de mejoras potenciales en velocidad:
+
+![Diagram: Amdahl's Law](./images/amdahls_law.png)
+
+*(Imagen de Referencia: Por Daniels220 en Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)*
+
+Como podemos ver, incluso un programa el cual es un 50% paralelizable se beneficiará muy poco más allá de 10 unidades de procesamiento, mientras que un programa el cual es 95% paralelizable todavía puede alcanzar mejoras significativas de velocidad con más de mil unidades de procesamiento.
+
+A medida que la [Ley de Moore](#ley-de-moore) se ralentiza y la aceleración de la velocidad del procesador individual disminuye, la paralelización es la clave para incrementar el rendimiento. la 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).
+
+Vea también:
+
+- [Ley de Brooks](#ley-de-brooks)
+- [Ley de Moore](#ley-de-moore)
+
+### Ley de Brooks
+
+[Ley de Brooks en Wikipedia](https://es.wikipedia.org/wiki/Ley_de_Brooks)
+
+> Cuando se incorpora una persona en un proyecto, éste se ralentiza en lugar de acelerarse. Brooks también afirmó que "Nueve mujeres no pueden tener un bebé en un mes".
+
+Esta ley sugiere que en muchos casos, intentar acelerar la entrega de un proyecto el cual ya va tarde, agregando más personas, hará que la entrega vaya aún más tarde. Brooks clarifica que esto es una simplificación, sin embargo, el razonamiento general es que el tiempo de aceleración de nuevos recursos y la sobrecarga de comunicación, en el inmediato corto plazo hace que la velocidad caiga. También, muchas tareas pueden no ser divisibles, es decir que pueden no ser fácilmente distribuibles entre más personas, significando que el potencial incremento de velocidad es incluso menor.
+
+La frase común en entregas "Nueve mujeres no pueden tener un bebé en un mes" está relacionada a la Ley de Brooks, en particular, al hecho de que algunos tipos de trabajos no son divisibles ni paralelizables.
+
+Este es el tema central del libro '[El Mítico Hombre Mes](#lista-de-lectura)'.
+
+Vea también:
+
+- [Marcha de la Muerte](#todo)
+- [Lista de Lectura: El Mítico Hombre Mes](#reading-list)
+
+### Ley de Conway
+
+[La Ley de Conway en Wikipedia](https://es.wikipedia.org/wiki/Ley_de_Conway)
+
+Esta ley sugiere que los límites técnicos de un sistema reflejan la estructura de la organización. Es comúnmente referido a cuando se observan mejoras de una organización, la Ley de Conway sugiere que si una organización es estructurada en muchas unidades pequeñas y desconectadas, el software que producirá será así. Si una organización es construída más entorno a soluciones 'verticales' las cuales están orientadas alrededor de características o servicios, los sistemas de software también reflejarán esto.
+
+Vea también:
+
+- [El Modelo Spotify](#el-modelo-spotify)
+
+### Ley de Cunningham
+
+[Ley de Cunningham en Wikipedia](https://meta.wikimedia.org/wiki/Cunningham%27s_Law/es)
+
+> La mejor forma de obtener la respuesta correcta en Internet no es hacer una pregunta, es enviar la respuesta errónea.
+
+Acorde a Steven McGeady, Ward Cunningham le aconsejó a principios de los 80: "La mejor forma de obtener la respuesta correcta en Internet no es hacer una pregunta, es enviar una respuesta incorrecta." McGeady lo llamó la Ley de Cunningham, sin embargo Cunningham niega su propiedad diciendo que es una cita errónea. Aunque originalmente se refiere a las interacciones en Usenet, la ley ha sido usada para describir como otras comunidades online funcionan (e.g., Wikipedia, Reddit, Twitter, Facebook).
+
+Vea también:
+
+- [XKCD 386: "Duty Calls" (El Deber Llama)](https://xkcd.com/386/)
+
+### El Número de Dunbar
+
+[El Número de Dunbar en Wikipedia](https://es.wikipedia.org/wiki/N%C3%BAmero_de_Dunbar)
+
+"El número de Dunbar es un límite cognitivo sugerido sobre el número de personas con las que puedes mantener relaciones sociables estables- relaciones en las que un individuo sabe quien es la otra persona and cómo cada persona se relaciona con cada una de las otras personas." Hay algún desacuerdo sobre el número exacto. "... [Dunbar] propuso que los humanos pueden mantener cómodamente solo 150 relaciones estables." El puso el número dentro de un contexto más social, "el número de personas con las que no sentirías vergüenza de invitarlas a tomar una copa
+"Dunbar's number is a suggested cognitive limit to the number of people with whom one can maintain stable social relationships— relationships in which an individual knows who each person is and how each person relates to every other person." There is some disagreement to the exact number. "... [Dunbar] proposed that humans can comfortably maintain only 150 stable relationships." He put the number into a more social context, "la cantidad de personas de las que no te sentirías avergonzado por unirte sin invitación a tomar una copa si te topas con ellas en un bar." Estima que el número puede rondar generalmente entre 100 y 250.
+
+Al igual que relaciones estables entre individuos, la relación de un desarrollador con su código base toma esfuerzo mantenerla. Cuando afrontas un gran número de proyectos complicados o creas muchos proyectos, nos apoyamos en convenciones, políticas y modelamos procedimientos para escalar. El número de Dunbar no es solo importante para tener en mente como una oficina crece, también cuando configuramos el alcance de los esfuerzos de un equipo o decidimos cuando debemos invertir en herramientas para asistir en el modelado y automatizar el sobregasto logístico. Poniendo el número en el contexto de ingeniería, es el número de proyectos (o complejidad normalizada de un único proyecto) para los cuales podrías sentirte seguro de unirte para las rondas de soporte telefónico.
+
+Vea también:
+
+- [Ley de Conway](#ley-de-conway)
+
+### Ley de Gall
+
+[Ley de Gall en Wikipedia (inglés)](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law)
+
+> Un sistema complejo que funciona ha sido evolucionado invariablemente desde un sistema simple que funcionaba. Un sistema complejo diseñado desde cero nunca funcionará y no puede ser arreglado para que funcione. Tienes que comenzar de nuevo con un sistema simple que funcione.
+>
+> ([John Gall](https://en.wikipedia.org/wiki/John_Gall_(author)))
+
+
+La Ley de Gall implica que los intentos de _diseñar_ un sistema altamente complejo tenderán siempre a fallar. Sistemas altamente complejos son raramente construidos de una sola vez, estos suelen ser evoluciones de sistemas mucho más simples.
+
+El ejemplo clásico es la World Wide Web (WWW). En su estado actual, es un sistema altamente complejo. Sin embargo, esta fue definida inicialmente como una forma simple de compartir contenido entre instituciones académicas. Esta fue un éxito cumpliendo sus objetivos y evolucionó para llegar a ser más compleja con el tiempo.
+
+Vea también:
+
+- [KISS (Keep It Simple, Stupid)](#el-principio-kiss)
+
+### La Navaja de Hanlon
+
+[La Navaja de Hanlon en Wikipedia](https://es.wikipedia.org/wiki/Principio_de_Hanlon)
+
+> Nunca atribuyas a la malicia lo que puede ser adecuadamente explicado por la estupidez.
+>
+> Robert J. Hanlon
+
+Este principio sugiere que las acciones resultantes en un resultado negativo no fueron resultado de una mala intención. En su lugar el resultado negativo es mejor atribuído a que esas acciones y/o el impacto no fueron completamente entendidos.
+
+### Ley de Hofstadter
+
+[Ley de Hofstadter en Wikipedia](https://es.wikipedia.org/wiki/Ley_de_Hofstadter)
+
+> Siempre lleva más tiempo de lo que esperas, incluso si tienes en cuenta la Ley de Hofstadter.
+>
+> (Douglas Hofstadter)
+
+Quizás hayas oído esta ley referida a cuando se busca estimar el tiempo que tomará algo. Esto parece una verdad absoluta en el desarrollo de software donde tendemos a no ser muy buenos estimando con precisión cuanto tiempo tomará entregar algo.
+
+Esto proviene del libro '[Gödel, Escher, Bach: An Eternal Golden Braid](#lista-de-lectura)'.
+
+Vea también:
+
+- [Lista de lectura: Gödel, Escher, Bach: An Eternal Golden Braid](#lista-de-lectura)
+
+### Ley de Hutber
+
+[Ley de Hutber en Wikipedia (inglés)](https://en.wikipedia.org/wiki/Hutber%27s_law)
+
+> Mejorar signfica deteriorar.
+>
+> ([Patrick Hutber (inglés)](https://en.wikipedia.org/wiki/Patrick_Hutber))
+
+Esta ley sugiere que las mejoras realizadas en un sistema llevarán a su deterioro en otras partes, u ocultará otros deterioros, llevando a una degradación total del estado actual del sistema.
+
+Por ejemplo, un decremento en la latencia de respuesta para un end-point particular podría causar problemas de rendimiento y capacidad de procesamiento más adelante en el flujo de peticiones, afectando a un subsistema completamente diferente.
+
+### El Ciclo de Sobreexpectación y La Ley de Amara
+
+[El Ciclo de Sobreexpectación](https://es.wikipedia.org/wiki/Ciclo_de_sobreexpectaci%C3%B3n)
+
+> Tendemos a sobreestimar el efecto de una tecnología a corto plazo y subestimar su efecto a largo plazo.
+>
+> (Roy Amara)
+
+El Ciclo de Sobreexpectación es una representación visual de la excitación y desarrollo de tecnología a lo largo del tiempo, originalmente producido por Gartner. Se explica mejor de forma visual:
+
+![El Cico de Sobreexpectación](./images/gartner_hype_cycle.png)
+
+*(Referencia de Imagen: Por Jeremykemp en Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)*
+
+En pocas palabras, el ciclo sugiere que hay una típica burbuja de excitación alrededor de cada nueva tecnología y su impacto potencial. Los equipos a veces saltan rápidamente a emplear estas tecnologías y a veces se encuentran a sí mismos decepcionados con los resultados. Esto puede ser porque la tecnología no es aún lo suficientemente madura, o las aplicaciones del mundo real no están completamente desarrolladas. Después de cierto tiempo, las capacidades de la tecnología se incrementan y las oportunidades de ser empleada de forma práctica aumentan permitiendo a los equipos ser finalmente productivos. La frase de Roy Amara resume este hecho de forma breve - "Tendemos a sobreestimar el efecto de una tecnología a corto plazo y subestimarla a largo plazo".
+
+### Ley de Hyrum (La Ley de las Interfaces Implícitas)
+
+[Ley de Hyrum (inglés)](http://www.hyrumslaw.com/)
+
+> Con un número suficiente de usuarios de una API,
+> no importa que prometas en el contrato:
+> alguien dependerá de todos los comportamientos observables
+> de tu sistema.
+>
+> (Hyrum Wright)
+
+La Ley de Hyrum establece que cuando tienes un _número grande y suficiente de consumidores_ de una API, todos los comportamientos de la API (incluso aquellos no definidos como parte del contrato público) llegarán de forma eventual a ser dependencia de alguien. Un ejemplo trivial pueden ser los elementos no-funcionales como el tiempo de respuesta de una API. Un ejemplo más sutil puede ser qué consumidores están dependiendo en la aplicación de una expresión regular sobre un mensaje de error para determinar el *tipo* de error de una API. Incluso si el contrato público de la API no establece nada acerca del contenido del mensaje de error indicando a los usuarios que deben emplear un código de error, _algunos_ usuarios usarán el mensaje y cambiar el mensaje esencialmente romperá la API para estos usuarios.
+
+Vea también:
+
+- [La Ley de las Abstracciones Permeables](#la-ley-de-las-abstracciones-permeables)
+- [XKCD 1172](https://xkcd.com/1172/)
+
+
+### Ley de Metcalfe
+
+[Ley de Metcalfe en Wikipedia (inglés)](https://en.wikipedia.org/wiki/Metcalfe's_law)
+
+> En teoría de redes, el número en el que un sistema crece es aproximadamente el cuadrado del número de usuarios de ese sistema.
+
+Esta ley está basada en el número de posibles conexiones por pares dentro de un sistema y está muy relacionado con [La Ley de Reed](#ley-de-reed). Odlyzko y otros han argumentado que ambas leyes (Reed y Metcalfe) exageran el valor de un sistema por no tener en cuenta los límites de la cognición humana en efectos de redes; vea [El Número de Dunbar](#numero-de-dunbar).
+
+Vea también:
+- [Ley de Reed](#ley-de-reed)
+- [Número de Dunbar](#numero-de-dunbar)
+
+### Ley de Moore
+
+[Ley de Moore en Wikipedia](https://es.wikipedia.org/wiki/Ley_de_Moore)
+
+> El número de transistores en un circuito integrado se dobla aproximadamente cada dos años.
+
+A veces empleado para ilustrar la velocidad pura a la que un semiconductor y la tecnología de chips ha mejorado, la predicción de Moore probó ser altamente precisa desde los 70 hasta finales de la primera década de 2000. En los años recientes, la tendencia ha cambiado ligeramente, parcialmente debido a [las limitaciones físicas en el grado en el que los componentes pueden ser miniaturizados (inglés)](https://en.wikipedia.org/wiki/Quantum_tunnelling). Sin embargo, los avances en la paralelización y potencialmente los cambios revolucionarios en la tecnología de semiconductores y computación cuántica puedan significar que la Ley de Moore continúe siendo cierta en las siguientes décadas.
+
+### Ley de Murphy / Ley de Sod
+
+[Ley de Murphy en Wikipedia](https://es.wikipedia.org/wiki/Ley_de_Murphy)
+
+> Si algo puede ir mal, irá mal.
+
+Relacionado con [Edward A. Murphy, Jr](https://es.wikipedia.org/wiki/Edward_A._Murphy_Jr.) la _Ley de Murphy_ establece que si algo puede ir mal, irá mal.
+
+Este dicho es muy común entre desarrolladores. A veces algo inesperado sucede cuando se desarrolla, se hacen pruebas o incluso en producción. Esto puede relacionarse también a la (más común en inglés británico) _Ley de Sod_:
+
+> Si algo puede ir mal, irá mal, en el peor momento posible.
+
+Estas leyes son generalmente empleadas en sentido cómico. Sin embargo, tales fenómenos como la [_Sesgo de Confirmación_](#por-hacer) y [_Sesgo de Selección_](#por-hacer) pueden llevar a la gente a sobre-enfatizar estas leyes (la mayoría de las veces cuando las cosas funcionan, estas pasan sin tenerse en cuenta, mientras que los fallos son muy notalbes y entran más en las conversaciones).
+
+Vea también:
+
+- [Sesgo de Confirmación](#por-hacer)
+- [Sesgo de Selección](#por-hacer)
+
+### Ley de Parkinson
+
+[Ley de Parkinson en Wikipedia](https://es.wikipedia.org/wiki/Ley_de_Parkinson)
+
+> El trabajo se expande hasta llenar el tiempo disponible para que se termine.
+
+En su contexto original, esta Ley se basó en estudios de burocracias. Esta podía ser aplicada de forma pesimista a las iniciativas de desarrollo de software, la teoría sería que los equipos serán ineficientes hasta que la fecha de entrega esté cerca, entonces se apresurarán a completar el trabajo para la entrega, haciendo la fecha de entrega real de algún modo arbitraria.
+
+Si esta ley se combina con la [Ley de Hofstadter](#ley-de-hofstadter), un punto de vista incluso más pesimista es alcanzado - el trabajo se expandirá hasta rellenar el tiempo disponible para su compleción y *aún tomará más tiempo del esperado*.
+
+Vea también:
+
+- [Ley de Hofstadter](#ley-de-hofstadter)
+
+### Efecto de Optimización Prematura
+
+[Optimización Prematura en Wikipedia](https://es.wikipedia.org/wiki/Optimizaci%C3%B3n_de_software#Cu%C3%A1ndo_optimizar)
+
+> Debemos olvidar las pequeñas eficiencias, por ejemplo, el 97% del tiempo: la optimización prematura es la raíz de todos los males.
+>
+> [(Donald Knuth, diciembre de 1974)](https://twitter.com/realdonaldknuth)
+
+En el documento de Donald Knuth titulado [Programación Estructurada con Mandatos Go To (inglés)](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements), escribió: "Los programadores desperdician enormes cantidades de tiempo pensando o preocupándose acerca de la velocidad de partes no-críticas de sus programas, y esos intentos de eficiencia en realidad tienen un impacto negativo cuando consideramos la depuración o el mantenimiento. Debemos olvidar las pequeñas eficiencias, por ejemplo, el 97% del tiempo: **la optimización prematura es la raíz de todos los males**. Aunque no debemos dejar pasar nuestras oportunidades en ese crítico 3%."
+
+Sin embargo, _Premature Optimization_ puede ser definido (en términos menos cargados) como nosotros sabemos lo que tenemos que hacer.
+
+### Ley de Putt
+
+[Ley de Putt (inglés)](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat)
+
+> La Tecnología es dominada por dos tipos de personas, aquellos quienes comprenden lo que no controlan y aquellos quienes controllan lo que no entienden.
+
+La Ley de Putt a veces es seguida por el Corolario de Putt:
+
+> Cada jerarquía técnica, con el tiempo, desarrolla una inversión de competencia.
+
+Estos mandatos sugieren que debido a varios criterios de selección y tendencias en cómo los grupos se organizan, habrá un número de personas cualificadas en los niveles de trabajo de una organización técnica y una cantidad de personas en roles directivos que no son conscientes de las complejidades y desafíos del trabajo que están manejando. Esto puede ser debido al fenómenos tales como [El Principio de Peter](#el-principio-de-peter) o [El Principio de Dilbert](#el-principio-de-dilbert).
+
+Sin embargo, debe enfatizarse que leyes como esta son generalizaciones amplias y pueden aplicarse a _algunos_ tipos de organizaciones y no a otras.
+
+Vea también:
+
+- [El Principio de Peter](#el-principio-de-peter)
+- [El Principio de Dilbert](#el-principio-de-dilbert)
+
+### La Ley de Reed
+
+[La Ley de Reed en Wikipedia (inglés)](https://en.wikipedia.org/wiki/Reed's_law)
+
+> La utilidad de redes grandes, particularmente redes sociales, escala exponencialmente con el tamaño de la red.
+
+Esta ley está basada en la teoría de grafos, donde la utilidad escala como el número de posibles sub-grupos, el cuál es más rápido que el número de participantes o el número de posibles conexiones p
+Esta ley se basa en la teoría de grafos, donde la utilidad se escala como el número de subgrupos posibles, que es más rápido que el número de participantes o el número de posibles conexiones por pares. Odlyzko y otros han argumentado que la Ley de Reed exagera la utilidad del sistema al no tener en cuenta los límites de la cognición humana sobre los efectos de la red; ver [El Número de Dunbar](#numero-de-dunbar).
+
+See also:
+- [La Ley de Metcalfe's Law](#metcalfes-law)
+- [Número de Dunbar](#numero-de-dunbar)
+
+### Ley de Conservación de Complejidad (Ley de Tesler)
+
+[La Ley de Conservación de Complejidad en Wikipedia (inglés)](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity)
+
+Esta ley establece que hay una cierta cantidad de complejidad en un sistema la cuál no puede ser reducida.
+
+Cierta complejidad en un sistema puede ser 'involuntaria'. Es consecuencia de una estructura deficiente, errores o tan solo un mal modelo de un problema a resolver. La complejidad involuntaria puede ser reducida (o eliminada). Sin embargo, cierta complejidad es 'intrínseca' como consecuencia de la complejidad inherente de un problema que se está resolviendo. Esta complejidad puede ser desplazada, pero no eliminada.
+
+Un elemento interesate de esta ley es la sugerencia de que incluso simplificando el sistema entero, la complejidad intrínseca no se reduce, esta se _desplaza hacia el usuario_, el cuál debe comportarse de una forma compleja.
+
+### Ley de las Abstracciones Permeables
+
+[La Ley de las Abstracciones Permeables en Joel on Software (inglés)](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/)
+
+> Toda abstracción no trivial, en algún grado, es permeable.
+>
+> ([Joel Spolsky](https://twitter.com/spolsky))
+
+Esta ley establece que las abstracciones, las cuales son generalmente usadas en computación para simplificar el trabajo con sistemas complicados, en ciertas situaciones 'filtrarán' sus elementos a un sistema subyacente, haciendo que la abstracción se comporte de una forma inesperada.
+
+Un ejemplo puede ser la carga de un fichero y lectura de sus contenidos. Las APIs del sistema de ficheros son una _abstracción_ del bajo nivel de los sistemas del kernel, los cuales son en sí mismos abstracciones de los procesos físicos relacionados con el cambio de información en un disco magnético (o memoria flash para un SSD). En la mayoría de los casos, funcionará la abstracción de tratar al fichero como un flujo de datos binarios. Sin embargo, para un disco magnético, leer datos secuenciales puede ser *significativamente* más rápido que los accesos aleatorios (debido al aumento de la sobrecarga de fallas), pero no para un disco SSD donde este aumento no estará presente. Los detalles subyacentes necesitarán ser entendidos para tratar cada caso (por ejemplo, índices de base de datos son estructurados para reducir la sobrecarga del acceso aleatorio), la abstracción 'filtra' detalles de la implementación al desarrollador que pueda necesitar tener en cuenta.
+
+El ejemplo anterior puede llegar a ser aún más complejo cuando _más_ abstracciones sean introducidas. El sistema operativo Linux permite acceder a ficheros en red pero representados de forma local como ficheros 'normales'. Esta abstracción 'filtrará' si hay errores de red. Si un desarrollador trata estos ficheros como 'normales', sin considerar el hecho de que puedan estar sujetos a latencia de red y fallos, las soluciones serán defectuosas.
+
+El artículo que describe esta ley sugiere que una dependenica excesiva de abstracciones, combinada con un entendimiento deficiente del proceso subyacente, en realidad hace que tratar con el problema sea _más_ complejo en algunos casos.
+
+Vea también:
+
+- [Ley de Hyrum](#ley-de-hyrum-la-ley-de-las-interfaces-implicitas)
+
+Ejemplos del Mundo-Real:
+
+- [Inicio lento en Photoshop (inglés)](https://forums.adobe.com/thread/376152) - un problema que encontré en el pasado. Photoshop podría tener un inicio lento, algunas veces tomando incluso minutos. Parece que el problema fue debido a que al inicio lee cierta información sobre la impresora por defecto. Sin embargo, si la impresora está en red, esto puede tomar mucho tiempo. La _abstracción_ de una impresora en red siendo presentada al sistema de forma similar a una impresora local causó un problema para usuarios en situaciones de conectividad de red deficiente.
+
+### Ley de la Trivialidad
+
+[Ley de la Trivialidad en Wikipedia (inglés)](https://en.wikipedia.org/wiki/Law_of_triviality)
+
+Esta ley sugiere que los grupos invertirán mucho más tiempo y atención a problemas triviales y cosméticos que a problemas serios y sustanciales.
+
+El ejemplo común y ficticio usado para ilustrarlo es que un comité aprobando planes para una planta nuclear invertirá la mayor parte del tiempo discutiendo la estructura del aparcamiento de bicicletas que diseños mucho más importantes para la planta nuclear en sí misma. Puede ser difícil hacer aportes valiosos en las discusiones sobre temas muy grandes y complejos sin un alto grado de experiencia y preparación en el tema. Sin embargo, la gente quiere ser vista contribuyendo de forma valiosa. De ahí la tendencia a enfocarse demasiado en detalles pequeños, los cuales pueden ser razonados fácilmente, pero no necesariamente de particular importancia.
+
+El ejemplo ficticio de arriba nos lleva al uso del término 'Aparcamiento de Bicicletas' (Bike Shedding) como una expresión para el desperdicio del tiempo en detalles triviales.
+
+### Filosofía Unix
+
+[La Filosofía Unix en Altenwald](https://altenwald.org/2008/09/22/filosofia-unix/)
+
+La Filosofía Unix es que los componentes de software debe ser pequeños y enfocados en hacer tan solo una cosa bien. Esto puede hacer más fácil construir sistemas a través de la composición conjunta de pequeñas, simples y bien definidas unidades mejor que usar programas grandes, complejos y multi-propósito.
+
+Prácticas modernas como 'Arquitectura de Microservicios' pueden ser pensadas como una aplicación de esta ley, donde los servicios son pequeños, enfocados y hacen una cosa específica, permitiendo componer comportamientos más complejos compuestos de bloques de construcción simples.
+
+### El Modelo Spotify
+
+[El Modelo Spotify en Spotify Labs (inglés)](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/)
+
+El Modelo Spotify es un enfoque a una estructura de organización la cual ha sido popularizada por 'Spotify'. En este modelo, los equipos son organizados alrededor de características en lugar de tecnologías.
+
+El Modelo Spotify también popularizó los conceptos de Tribus, Gremios y Capítulos, los cuales son otros componentes de su estructura de organización.
+
+### Ley de Wadler
+
+[Ley de Wadler en wiki.haskell.org (inglés)](https://wiki.haskell.org/Wadler's_Law)
+
+> En cualquier diseño de lenguaje, el total de tiempo invertido en discutir una característica en su lista es proporcional a dos elevado a la potencia de su posición:
+>
+> 0. Semántica
+> 1. Sintaxis
+> 2. Sintaxis Léxica
+> 3. Sintaxis Léxica de Comentarios
+>
+> (En pocas palabras, por cada hora invertida en semántica, 8 horas serán invertidas en la sintaxis de los comentarios).
+
+Similar a [La Ley de la Trivialidad](#ley-de-la-trivialidad), la Ley de Walder establece que cuando un se diseña un lenguaje, la cantidad de horas invertida en las estructuras del lenguaje es desproporcionadamente alta en comparación a la importancia de estas características.
+
+Vea también:
+
+- [La Ley de la Trivialidad](#ley-de-la-trivialidad)
+
+## Principios
+
+Los Principios son generalmente más propensos a ser pautas relacionadas al diseño.
+
+### El Principio de Dilbert
+
+[El Principio de Dilbert en Wikipedia (inglés)](https://en.wikipedia.org/wiki/Dilbert_principle)
+
+> Las compañías tienden sistémicamente a promocionar empleados incompetentes a dirección para eliminarlos del flujo de trabajo.
+>
+> _Scott Adams_
+
+Un concepto de administración desarrollado por Scott Adams (creador de la tira cómica de Dilbert), el Principio de Dilbert está inspirado por [El Principio de Peter](#el-principio-de-peter). Bajo el Principio de Dilbert, los empleados que nunca fueron competentes son promocionados a cargos directivos para limitar el daño que pueden hacer. Adams primero explicó el principio en 1995 en un artículo del Wall Street Journal y lo expandió en su libro de negocios publicado en 1996, [The Dilbert Principle (inglés)](#lista-de-lectura).
+
+Vea también:
+
+- [El Principio de Peter](#el-principio-de-peter)
+- [Ley de Putt](#ley-de-putt)
+
+### El Principio de Pareto (La Regla 80/20)
+
+[El Principio de Pareto en Wikipedia](https://es.wikipedia.org/wiki/Principio_de_Pareto)
+
+> La mayoría de cosas en la vida no se distribuyen de forma uniforme.
+
+El Principio de Pareto sugiere que en algunos casos, la mayoría de los resultados vienen de la minoría de entradas:
+
+- El 80% de un cierto trozo de software puede ser escrito con el 20% del total de tiempo asignado (a la inversa, el 20% del código más difícil toma el 80% del tiempo).
+- El 20% del esfuerzo produce el 80% del resultado
+- El 20% del trabajo crea el 80% de los ingresos
+- El 20% de los fallos causa el 80% de los problemas
+- El 20% de las características se emplean 80% más que el resto
+
+En los años 1940s el ingeniero americano-romaní Dr. Joseph Juran, quien es ampliamente reconocido por atribuírsele ser el padre del control de calidad, [comenzó a aplicar el principio de Pareto a problemas de calidad](https://es.wikipedia.org/wiki/Joseph_Juran).
+
+Este principio es también conocido como: La Regla 80/20, La Ley de los Pocos Vitales y el Principio del Factor de Escasez.
+
+Ejemplos del Mundo-Real:
+
+- En 2002 Microsoft reportó que arreglando el 20% de los errores más reportados, 80% de los errores relacionados y los crashes en Windows y Office habían sido eliminados ([Referencia (en inglés)](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)).
+
+### El Principio de Peter
+
+[El Principio de Peter en Wikipedia](https://es.wikipedia.org/wiki/Principio_de_Peter)
+
+> La gente en una jerarquía tiende a ascender hasta su "nivel de incompetencia".
+>
+> _Laurence J. Peter_
+
+Un concepto de administración de Laurence J. Peter, el Principio de Peter observa que la gente que es buena en sus trabajos es promocionada hasta llegar a un nivel donde ya no son tan exitosos (su "nivel de incompetencia"). En este punto, como ellos son más _senior_, son menos propensos a ser eliminados de la organización (a menos que su rendimiento sea espectacularmente malo) y continuarán en un rol en el que tienen pocas habilidades intrínsecas. Las habilidades que les hicieron exitosos no son necesariamente las habilidades requeridas para sus nuevos puestos.
+
+Este es de particular interés para los ingenieros - quienes inicialmente comienzan en roles profundamente técnicos, pero a veces tienen una carrera la cual les guía a _administrar_ a otros ingenieros - los cuales requieren un conjunto fundamentalmente diferente de habilidades.
+
+Vea también:
+
+- [El Principio de Dilbert](#el-principio-de-dilbert)
+- [La Ley de Putt](#ley-de-putt)
+
+### El Principio de Robustez (Ley de Postel)
+
+[El Principio de Robustez en Wikipedia (inglés)](https://en.wikipedia.org/wiki/Robustness_principle)
+
+> Sé conservador en lo que haces y liberal con lo que recibes de otros.
+
+A veces aplicado en desarrollo de aplicaciones de servidor, este principio establece que lo que tú envias a otros debe ser tan mínimo y consensuado como sea posible, pero lo que deberías tener como objetivo es permitir la entrada no consensuada si es que puede ser procesada.
+
+El objetivo de este principio es construir sistemas los cuales sean robustos, tanto que puedan manejar entradas algo deficientes si aún pueden ser entendidas. Sin embargo, hay potenciales implicaciones de seguridad acerca de aceptar entradas mal formadas, particularmente si el procesamiento de tales entradas no ha sido bien testeado.
+
+### SOLID
+
+Este es un acrónimo el cual se refiere a:
+
+* S: [El Principio de Responsabilidad Única](#principio-de-responsabilidad-unica) (S por _Single Responsability_ del inglés)
+* O: [El Principio Abierto/Cerrado](#principio-abierto-cerrado) (O por _Open/Close_)
+* L: [El Principio de Sustitución de Liskov](#principio-de-sustitucion-de-liskov) (L por _Liskov_)
+* I: [El Principio de Segregación de Interfaces](#principio-de-segregacion-de-interfaces) (I por _Interfaces Segregation_)
+* D: [El Principio de Inversión de Dependencia](#principio-de-inversion-de-dependencia)
+
+Estos son los principios clave en la [Programación Orientada a Objetos](#por-hacer). Los principios de diseño tales como estos deben servir de ayuda a desarrolladores para construir sistemas más mantenibles.
+
+### Principio de Responsabilidad Única
+
+[El Principio de Responsabilidad Única en Wikipedia](https://es.wikipedia.org/wiki/Principio_de_responsabilidad_%C3%BAnica)
+
+> Cada módulo o clase debe tener una tan solo una única responsabilidad.
+
+El primero de los principios '[SOLID](#solid)'. Este principio sugiere que los módulos o clases deben hacer una única cosa y solo una. En términos más prácticos, esto quire decir que una único, pequeño cambio a una característica de un programa debe requerir un cambio en un solo componente. Por ejemplo, cambiar como una contraseña es validada por complejidad debe requerir un cambio en solo una parte del programa.
+
+Teóricamente, esto debe hacer el código más robusto (sólido) y fácil de cambiar. Sabiendo que un componente el cual está siendo modificado tiene una única responsabilidad sólo significa que _comprobar_ ese cambio dede ser más fácil. Usando el ejemplo anterior, cambiar el componente de complejidad de la contraseña debe solo afectar a las características relacionadas con la complejidad de la contraseña. Puede ser mucho más difícil tener en cuenta el impacto de un cambio en un componente el cual tiene muchas responsabilidades.
+
+Vea también:
+
+- [Programación Orientada a Objetos](#por-hacer)
+- [SOLID](#solid)
+
+### Principio de Abierto/Cerrado
+
+[Principio de Abierto/Cerrado](https://es.wikipedia.org/wiki/Principio_de_abierto/cerrado)
+
+> Las entidades deben estar abiertas para ser extendidas y cerradas para ser modificadas.
+
+El segundo de los principios '[SOLID](#solid). Este principio establece que las entidades (las cuales pueden ser clases, módulos, funciones u otras similares) deben tener la capacidad para ser _extendidas_ (ampliadas), pero de la misma forma debe _existir_ en su comportamiento la capacidad de no ser modificadas.
+
+Como un ejemplo hipotético, imagina un módulo el cual es capaz de convertir un documento Markdown en uno HTML. Si el módulo puede ser ampliado para manejar nuevas características de Markdown, sin modificar el funcionamiento interno del módulo, entonces podemos decir que está abierto para ser ampliado para su extensión. Si el módulo _no_ pudiera ser modificado por un consumidor de manera que se manejen las características existentes de Markdown, entonces se_cierra_ para su modificación.
+
+Este principio tiene una relevancia particular para la programación orientada a objetos, donde el diseño de objetos puede ser extendido (a través de la herencia), pero evitaríamos diseñar objetos los cuales puedan cambiar su comportamiento existente de formas inesperadas.
+
+Vea también:
+
+- [Programación Orientada a Objetos](#por-hacer)
+- [SOLID](#solid)
+
+### Principio de Sustitución de Liskov
+
+[El Principio de Sustitución de Liskov en Wikipedia](https://es.wikipedia.org/wiki/Principio_de_sustituci%C3%B3n_de_Liskov)
+
+> Debe ser posible reemplazar un tipo con un subtipo, sin romper el sistema.
+
+El tercero de los principios '[SOLID](#solid)'. Este principio establece que si un componente se basa en un tipo, entonces debe ser capaz de usar subtipos de ese tipo, sin que el sistema falle o tenga constancia de los detalles de que es un subtipo.
+
+Como un ejemplo, imagina que tenemos un método el cual lee un documento XML desde una estructura la cual representa un fichero. Si el método usa un tipo base 'fichero', entonces cualquiera que derive de 'fichero' debe ser capaz de ser usado en la función. Si 'fichero' soporta la búsqueda inversa, y el parseador de XML usa esa función, y entonces el tipo derivado 'fichero de red' falla cuando intenta una búsqueda inversa, el tipo derivado 'fichero de red' violaría el principio.
+
+Este principio tiene particular relevancia en programación orientada a objetos, donde la jerarquía de tipos debe ser modelada con cuidado para evitar confundir a los usuarios de un sistema.
+
+Vea también:
+
+- [Programación Orientada a Objetos](#por-hacer)
+- [SOLID](#solid)
+
+### Principio de Segregación de Interfaces
+
+[El Principio de la Segregación de Interfaces en Wikipedia](https://es.wikipedia.org/wiki/Principio_de_segregaci%C3%B3n_de_la_interfaz)
+
+> Ningún cliente debe ser forzado a depender de métodos que no use.
+
+El cuarto de los principios de '[SOLID](#solid)'. Este principio establece que los consumidores de un componente no deben depender en funciones de ese componente que no estén empleando.
+
+Como un ejemplo, imagina que tenemos un método el cual lee un documento XML de una estructura la cual representa un fichero. Este solo necesita leer bytes, moverse adelante y atrás en el fichero. Si este método necesita ser actualizado porque una característica no relacionada al fichero cambia (tal como una actualización al modelo de permisos usado para representar la seguridad del fichero), entonces el principio queda invalidado. Sería mejor para el fichero implementar una interfaz 'flujo-con-búsqueda' y emplearla para el lector XML.
+
+El principio tiene particular relevancia en programación orientada a objetos, donde las interfaces, jerarquías y abstracciones de tipos son usados para [minimizar el acoplamiento](#por-hacer) entre los diferentes componentes. [La tipificación dinámica](#por-hacer) (más conocida como _Duck typing_ en inglés) es una metodología que fuerza este principio eliminando las interfaces explícitas.
+
+Vea también:
+
+- [Programación Orientada a Objetos](#por-hacer)
+- [SOLID](#solid)
+- [Tipificación dinámica](#por-hacer) (_Duck typing_)
+- [Desacoplado](#por-hacer)
+
+### Principio de Inversión de Dependencia
+
+[El Principio de Inversión de Dependencia en Wikipedia (inglés)](https://en.wikipedia.org/wiki/Dependency_inversion_principle)
+
+> Módulos de alto-nivel no deben depender en implementaciones de bajo nivel.
+
+El quinto de los principios '[SOLID](#solid)'. Este principio establece que la orquestación de componentes del más alto nivel deben no tener conocimiento de los detalles de sus dependencias.
+
+Como un ejemplo, imagina que tenemos un programa que lee metadatos de un sitio web. Asumimos que el componente principal pueda tener que saber acerca de un componente de descarga del contenido de la página web y luego un componente que pueda leer los metadatos. Si tenemos la inversión de dependenicas en mente, el componente principal dependerá solo de un componente abstracto el cual obtendrá los bytes de datos y luego un componente abstracto que será capaz de leer los metadatos del flujo de bytes. El componente principal no sabrá nada acerca de TCP/IP, HTTP, HTML, etc.
+
+Este principio es complejo, puede ser visto como 'inverso' a las dependencias esperadas de un sistema (de ahí el nombre). En la práctica, esto también significa que se separa la orquestación de un componente y debe asegurarse la implementación correcta de los tipos abstractos que son empleados (e.g. en el ejemplo anterior, _algo_ debe aún proporcionar el componente de lectura de los metadatos un descargador de ficheros HTTP y un lector de etiquetas meta de HTML). Este entonces toca patrones tales como [Inversión de Control](#por-hacer) y [Inyección de Dependencias](#por-hacer).
+
+Vea también:
+
+- [Programación Orientada a Objetos](#por-hacer)
+- [SOLID](#solid)
+- [Inversión de Control](#por-hacer)
+- [Inyección de Dependencias](#por-hacer)
+
+### Principio DRY
+
+[El Principio DRY en Wikipedia](https://es.wikipedia.org/wiki/No_te_repitas)
+
+> Cada pieza de conocimiento debe tener una representación única, no ambigua y autoritaria dentro de un sistema.
+
+DRY es el acrónimo en inglés para _Don't Repeat Yourself_ (No te repitas). Este principio se enfoca en ayudar a los desarrolladores a reducir las repeticiones de código y mantener la información en un único lugar y fue citado en 1999 por Andrew Hunt y Dave Thomas en el libro [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) (El Desarrollador Pragmático).
+
+> Lo contrario a DRY sería _WET_ (Write Everthing Twice, escribe todo dos veces o We Enjoy Typing, disfrutamos escribiendo)
+
+En la práctica, si tienes el mismo trozo de información en dos (o más) sitios diferentes, puedes usar DRY para mezclarlo en uno solo y reusarlo en cualquier lugar que lo quieras/necesites.
+
+Vea también:
+
+- [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+
+### Principio KISS
+
+[KISS en Wikipedia](https://es.wikipedia.org/wiki/Principio_KISS)
+
+> Keep it simple, stupid (Mantenlo simple, estúpido)
+
+El principio KISS establece que la mayoría de los sistemas funcionan mejor si se mantienen simples en lugar de complejos; por lo tanto, simplicidad debe ser el objetivo clave en el diseño y la complejidad innecesaria debe ser evitada. Originado en las fuerzas armadas de los Estados Unidos (U.S. Navy) en 1960, la frase ha sido asociada con la ingeniera aérea Kelly Johnson.
+
+El principio es mejor ejemplificado por la historia de Johnson manejando un equipo de ingenieros de diseño de herramientas, con el desafío del jet aircraft ellos debían diseñar sobretodo que fuese reparable por un mecánico medio en el campo y en condiciones de combate con solo esas herramientas. De aquí el "estúpido" refiriéndose a la relación entre la forma en que las cosas se rompen y la sofisticación de las herramientas disponibles para repararlas, no las capacidades de los ingenieros en sí mismos.
+
+Vea también:
+
+- [Ley de Gall](#ley-de-gall)
+
+### YAGNI
+
+[YAGNI en Wikipedia](https://es.wikipedia.org/wiki/YAGNI)
+
+Este es un acrónimo para (en inglés) _**Y**ou **A**ren't **G**onna **N**eed **I**t_ o _No vas a necesitarlo_.
+
+> Siempre implementar cosas cuando vayas a necesitarlas realmente, nunca cuando preveas que las necesitarás.
+>
+> ([Ron Jeffries](https://twitter.com/RonJeffries)) (XP co-fundador y autor del libro "Extreme Programming Installed")
+
+Este principio de _Extreme Programming_ (XP) sugiere a los desarrolladores que deben solo implementar funcionalidad que es necesaria para los requisitos inmediatos y evitar los intentos de predecir el futuro implementando funcionalidades que podrían necesitarse luego.
+
+Adherirse a este principio debe reducir la cantidad de código sin usar en la base de código y evitar tiempo y esfuerzo de ser malgastado en funcionalidades que no aportan valor.
+
+Vea también:
+
+- [Lista de lectura: Extreme Programming Installed](#lista-de-lectura)
+
+
+## Lista de Lectura
+
+Si has encontrado estos conceptos interesantes, puede que disfrutes estos libros:
+
+- [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Covers the core principles of Extreme Programming.
+- [El Mítico Hombre Mes](https://es.wikipedia.org/wiki/El_M%C3%ADtico_Hombre-Mes) - [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.
+- [The Dilbert Principle - Adam Scott](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-principl).
+- [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).
+
+## Por Hacer
+
+¡Hola! Si llegaste aquí es porque hiciste clic en un enlace a un tema que aún no ha sido escrito, perdón por eso, ¡este es aún un trabajo en proceso!
+
+Sé libre de [Abrir un _Issue_](https://github.com/manuel-rubio/hacker-laws/issues) para solicitar más detalles, o [abre una petición de cambio (_pull request_)](https://github.com/manuel-rubio/hacker-laws/pulls) para enviar tus definiciones propuestas acerca del asunto.

translations/it-IT.md

@@ -0,0 +1,537 @@
+# 💻📖 hacker-laws
+
+Leggi, teorie, principi e pattern utili agli sviluppatori.
+
+- 🇨🇳 [中文 / Traduzione in Cinese](https://github.com/nusr/hacker-laws-zh) - grazie [Steve Xu](https://github.com/nusr)!
+- 🇮🇹 [Traduzione in Italiano](https://github.com/csparpa/hacker-laws-it) - grazie [Claudio Sparpaglione](https://github.com/csparpa)!
+- 🇰🇷 [한국어 / Traduzione in Coreano](https://github.com/codeanddonuts/hacker-laws-kr) - grazie [Doughnut](https://github.com/codeanddonuts)!
+- 🇷🇺 [Русская версия / Traduzione in Russo](https://github.com/solarrust/hacker-laws) - grazie [Alena Batitskaya](https://github.com/solarrust)!
+- 🇹🇷 [Türkçe / Traduzione in Turco](https://github.com/umutphp/hacker-laws-tr) - grazie [Umut Işık](https://github.com/umutphp)!
+- 🇺🇸 [Original English Version - Versione Originale in Inglese](https://github.com/dwmkerr/hacker-laws) - grazie [Dave Kerr](https://github.com/dwmkerr)!
+
+---
+
+<!-- vim-markdown-toc GFM -->
+
+* [Introduzione](#introduzione)
+* [Leggi](#leggi)
+    * [Legge di Amdahl](#legge-di-amdahl)
+    * [Legge di Brooks](#legge-di-brooks)
+    * [Legge di Conway](#legge-di-conway)
+    * [Numero di Dunbar](#numero-di-dunbar)
+    * [Legge di Gall](#legge-di-gall)
+    * [Rasoio di Hanlon](#rasoio-di-hanlon)
+    * [Legge di Hofstadter](#legge-di-hofstadter)
+    * [Legge di Hutber](#legge-di-hutber)
+    * [Hype Cycle e Legge di Amara](#hype-cycle-e-legge-di-amara)
+    * [Legge di Hyrum (Legge delle Interfacce Implicite)](#legge-di-hyrum-legge-delle-interfacce-implicite)
+    * [Legge di Moore](#legge-di-moore)
+    * [Legge di Parkinson](#legge-di-parkinson)
+    * [Ottimizzazione Prematura](#effetto-di-ottimizzazione-prematura)
+    * [Legge di Putt](#legge-di-putt)
+    * [Legge di Conservazione della Complessità (Legge di Tesler)](#legge-di-conservazione-della-complessita-legge-di-tesler)
+    * [Legge dell'Astrazione Fallata](#legge-dell-astrazione-fallata)
+    * [Legge di Irrilevanza](#legge-di-irrilevanza)
+    * [Filosofia Unix](#filosofia-unix)
+    * [Il modello Spotify](#il-modello-spotify)
+    * [Legge di Wadler](#legge-di-wadler)
+* [Principi](#principi)
+    * [Il Principo di Pareto (La regola dell'80/20)](#principio-di-pareto-regola-dell-80-20)
+    * [Il Principio di Robustezza (Legge di Postel's)](#principio-di-robustezza-legge-di-postel)
+    * [SOLID](#solid)
+    * [Il Principio di Singola Responsabilità](#principio-di-singola-responsabilita)
+    * [Il Principio dell'Aperto/Chiuso](#principio-dell-open-closed)
+    * [Il Principio di Sostituzione di Liskov](#principio-di-sostituzione-di-liskov)
+    * [Il Principio di Segregazione delle Interfacce](#principio-di-segregazione-delle-interfacce)
+    * [Il Principio di Inversione delle Dipendenze](#principio-di-inversione-delle-dipendenze)
+    * [Il Principio DRY](#principio-dry)
+    * [YAGNI](#yagni)
+* [Reading List](#reading-list)
+* [TODO](#todo)
+
+<!-- vim-markdown-toc -->
+
+## Introduzione
+
+Quando si parla di sviluppo software, si discute di tanti principi. Questo repository fornisce un riferimento e un'introduzione a quelli più comuni. I contributi sono sono ben accetti!
+
+
+❗: Questo repo contiene la spiegazione di alcune leggi, principi e pattern, ma tuttavia non ne _sponsorizza_ nessuno. La loro applicabilità dovrebbe sempre essere discussa ed è sempre dipendente dal progetto specifico su cui state lavorando.
+
+## Leggi
+
+Si parte!
+
+### Legge di Amdahl
+
+[Legge di Amdahl su Wikipedia](https://it.wikipedia.org/wiki/Legge_di_Amdahl)
+
+> La legge di Amdahl mostra lo _speedup potenziale_ che può essere raggiunto nell'esecuzione di un calcolo aumentando le risorse del sistema di calcolo. Di norma si usa nel calcolo parallelo e può stimare il beneficio atteso, limitato dalla porzione parallelizzabile del programma, e raggiungibile aumentando il numero di core di calcolo.
+
+Ecco un esempio illustrativo. Se un programma è costituito da due parti - una parte A che deve essere eseguita da un singolo core di calcolo e una parte B che può essere parallelizzata - possiamo notare che aggiungere nuovi core al sistema di calcolo produce un beneficio limitato. L'aggiunta potenzia di molto la velocità di esecuzione della parte B - ma la velocità di esecuzione della parte A resterà la stessa.
+
+Il diagramma sotto riportato illustra gli andamenti nel tempo della velocità di esecuzione in alcuni casi:
+
+![Diagram: Amdahl's Law](./images/amdahls_law.png)
+
+*(Crediti Immagine: Daniels220 su Wikipedia in lingua inglese, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)*
+
+Come si può vedere, anche un programma che è al 50% parallelizzabile beneficerà molto poco dell'aggiunta di più di 10 core di calcolo, mentre un programma che è parallelizzabile al 95% può raggiungere speedup significativi nella velocità di esecuzione anche oltre 1000 core di calcolo aggiunti.
+
+Dal momento che [la legge di Moore](#legge-di-moore) sta rallentando, e l'aumento della velocità dei singoli core di calcolo diminuisce, parallelizzare diventa la chiave per migliorare le performance. Un eccellente esempio è la grafica computerizzata: con i moderni Shader, è possibile renderizzare in parallelo pixel e frammenti - questo è il motivo per cui le schede grafiche hanno migliaia di core di calcolo (GPU o Shader Unit)
+
+Vedi anche:
+
+- [Legge di Brooks](#legge-di-brooks)
+- [Legge di Moore](#legge-di-moore)
+
+### Legge di Brooks
+
+[Legge di Brooks su Wikipedia](https://it.wikipedia.org/wiki/Legge_di_Brooks)
+
+> L'aggiunta di risorse umane ad un progetto di sviluppo software già in ritardo lo fa tardare ancora di più.
+
+Questa legge suggerisce che in molti casi il tentativo di accelerare, tramite aggiunta di ulteriori persone a staff, la delivery di un progetto che è già in ritardo risulterà nell'aumento del ritardo progettuale. Brooks sottolinea che questo scenario è certamente molto semplificato, ma che tuttavia il ragionamento alla base è che il tempo necessario alle nuove risorse per diventare produttive e l'overhead di comunicazione introdotto causano una decrescita della velocità nel breve termine. Inoltre molti task risultano non suddivisibili o facilmente distribuibili tra più risorse, causando un corrispondente minor aumento nella velocità potenziale.
+
+La famosa frase "Nove donne non fanno un figlio in un solo mese" è relativa alla Legge di Brook, in particolare al fatto che alcuni tipi di operazioni non sono suddivisibili o parallelizzabili.
+
+Questo è un tema centrale del libro '[The Mythical Man Month](#reading-list)'.
+
+Vedi anche:
+
+- [Death March](#todo)
+- [Reading List: The Mythical Man Month](#reading-list)
+
+### Legge di Conway
+
+[Legge di Conway su Wikipedia](https://it.wikipedia.org/wiki/Legge_di_Conway)
+
+Questa legge indica che i confini di un sistema software riflettono la struttura dell'organizzazione che lo produce. Comunemente citata quando si parla di miglioramenti organizzativi, la legge di Conway afferma che se un'organizzazione è strutturata in tante piccole unità tra loro disconnesse, il software che essa produrrà avrà la stessa struttura. Se un'organizzazione invece è costruita attorno a "silo" verticali dedicati a funzionalità o servizi, i suoi sistemi software rifletteranno questa caratteristica.
+
+Vedi anche:
+
+- [Il modello Spotify](#il-modello-spotify)
+
+### Numero di Dunbar
+
+[Numero di Dunbar su Wikipedia](https://it.wikipedia.org/wiki/Numero_di_Dunbar)
+"Il numero di Dunbar è stato suggerito come valore cognitivo che limita il numero di persone con cui un individuo riesce a mantenere relazioni sociali stabili - relazioni in cui l'individuo sa chi è ciascuna controparte e come tutte le controparti si relazionano tra di loro". Non c'è concordanza sull'esatto valore di questo limite. "... Dunbar ha affermato che un essere umano può mantenere solo 150 relazioni stabili". Egli ha inserito questa affermazione in un contesto più sociale: "il numero di persone con cui ti sentiresti a tuo agio a prendere un drink se entrassi in un bar e le incontrassi casualmente". Le stime per il numero generalmente stanno tra 100 e 250.
+
+Come le relazioni stabili tra individui, le relazioni di uno sviluppatore con una codebase necessitano di impegno per essere mantenute. Quando ci troviamo di fronte a progetti grandi e complicati, o abbiamo la responsabilità di molti progetti, ci affidiamo a convenzioni, policy e procedure disegnate per scalare. Il numero di Dunbar non solo è importante da ricordare quando un ufficio cresce di dimensioni, ma anche quando si stabilisce il perimetro per l'operato di un team o quando si deve decidere se investire nella strumentazione per modellizzare e automatizzare l'overhead logistico. Inquadrando il numero di Dunbar in un contesto ingegneristico, esso rappresenta il numero di progetti (o la comoplessità normalizzata di un singolo progetto) sui quali un individuo si sentirebbe sicuro di lavorare a chiamata.
+
+Vedi anche:
+
+- [Legge di Conway](#legge-di-conway)
+
+### Legge di Gall
+
+[Legge di Gall su Wikipedia](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law)
+
+> Un sistema di complessità elevata e che funziona è inevitabilmente evoluto a partire da un sistema più semplice che funzionava. Un sistema complesso disegnato da zero non funziona per definizione e non può essere modificato per funzionare: bisogna partire ripartire da un sistema semplice che funziona.
+>
+> ([John Gall](https://en.wikipedia.org/wiki/John_Gall_(author)))
+
+La Legge di Gall implica che i tentativi di _disegnare_ un sistema ad alta complessità hanno alta probabilità di fallire. I sistemi complessi raramente sono costruiti in una sola iterazione, al contrario sono il risultato dell'evoluzione di sistemi più semplici.
+
+Un classico esempio è il World Wide Web. Al suo stato attuale, è un sistema fortemente complesso. Tuttavia, inizialmente fu definito come un sistema semplice per condividere contenuti tra istituti accademici. Realizzò questo obiettivo con grande successo ed mutò nel tempo divenendo sempre più complesso al passare del tempo.
+
+Vedi anche:
+
+- [KISS (Keep It Simple, Stupid)](#TODO)
+
+### Rasoio di Hanlon
+
+[Rasoio di Hanlon su Wikipedia](https://it.wikipedia.org/wiki/Rasoio_di_Hanlon)
+
+> Non attribuire mai a malafede quel che si può ragionevolmente spiegare con la stupidità.
+>
+> Robert J. Hanlon
+
+Questo principio suggerisce che l'ottenimento di un risultato negativo con ogni probabilità non è dovuto alla volontà perversa di fallire quanto alla mancata comprensione (totale o parziale) dell'impatto delle proprie azioni.
+
+### Legge di Hofstadter
+
+[Legge di Hofstadter su Wikipedia](https://it.wikipedia.org/wiki/Legge_di_Hofstadter)
+
+> Per fare una cosa ci vuole sempre più tempo di quanto si pensi, anche tenendo conto della Legge di Hofstadter.
+>
+> (Douglas Hofstadter)
+
+Questa legge è citata quando si fanno le stime sulla durata di qualcosa. Nello campo dello sviluppo software sembra essere un assioma la tendenza ad essere poco bravi nello stimare con precisione quanto tempo verrà richiesto per le delivery.
+
+La legge viene dal libro '[Gödel, Escher, Bach: An Eternal Golden Braid](#reading-list)'.
+
+Vedi anche:
+
+- [Reading List: Gödel, Escher, Bach: An Eternal Golden Braid](#reading-list)
+
+### Legge di Hutber
+
+[Legge di Hutber su Wikipedia](https://en.wikipedia.org/wiki/Hutber%27s_law)
+
+> I miglioramenti spesso celano altri peggioramenti.
+>
+> ([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber))
+
+La legge indica che i miglioramenti apportati ad una parte di un sistema porteranno ad un inevitabile deterioramento in altre sue parti, causando quindi un globale deterioramento nello stato corrente del sistema.
+
+Per esempio, la diminuzione nella latenza di risposta di uno specifico end-point provoca un amumento nel throughput e problemi di capacity nel workflow di gestione delle richieste, impattando altri sottosistemi correlati.
+
+### Hype Cycle e Legge di Amara
+
+[Hype Cycle su Wikipedia](https://it.wikipedia.org/wiki/Hype_cycle)
+
+> Tendiamo a sovrastimare l'impatto di una tecnologia sul breve termine e nel sottostimarlo sul lungo termine.
+>
+> (Roy Amara)
+
+L'Hype Cycle è una rappresentazione visuale del clamore attorno allo sviluppo di una tecnologia nel tempo, originariamente ideata da Gartner. Un esempio:
+
+![The Hype Cycle](./images/gartner_hype_cycle.png)
+
+*(Crediti Immagine: Jeremykemp su Wikipedia in lingua inglese, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)*
+
+In sintesi, il Cycle dice che tipicamente esiste un picco di frenesia quando nasce una nuova tecnologia riguardo i suoi potenziali impatti. I team di lavoro di solito adottano velocemente tali tecnologie e a volte si trovano scontenti del risultato. Ciò può essere dovuto all'immaturità della tecnologia, oppure alla mancanza di applicazioni reali significative. Dopo un certo periodo di tempo, le potenzialità della tecnologia aumentano e aumenta il numero delle opportunità concrete che essa offre, per cui i team di lavoro possono finalmente aumentare la loro produttività adottandola. La citazione di Roy Amara riassume in breve questa situazione - "Tendiamo a sovrastimare l'impatto di una tecnologia sul breve termine e nel sottostimarlo sul lungo termine".
+
+### Legge di Hyrum (Legge delle Interfacce Implicite)
+
+[Legge di Hyrum Online](http://www.hyrumslaw.com/)
+
+> Dato un numero sufficientementa elevato di utenti di un'API,
+> il contenuto del contratto di interfaccia non conta:
+> tutti i comportamenti osservabili del sistema che espone l'API
+> saranno utilizzati da questi utenti.
+>
+> (Hyrum Wright)
+
+La lagge di Hyrum dice che quando un'API ha un _numero sufficientementa elevato di consumer_, tutti i comportamenti di essa (anche quelli non definiti come parte dell'interfaccia pubblica) prima o poi costituiranno una dipendenza lato consumer. Un esempio banale è quello degli aspetti non-funzionali come il tempo di risposta di un'API. Un esempio più profondo è quello di consumer che applicano una regex sui messaggi di errore dell'API per determinarne la *tipologia*. Anche se il contratto pubblico di interfaccia un'API non dice nulla riguardo al contenuto dei messaggi e suggerisce agli utentil'utilizzo dei codici di errore associati ai messaggi, _alcuni_ utenti possono comunque utilizzare i messaggi di errore a tal fine e dunque una modifica dei messaggi sostanzialmente rompe l'integrazione per questi utenti.
+
+Vedi anche:
+
+- [Legge dell'Astrazione Fallata](#legge-dell-astrazione-fallata)
+- [XKCD 1172](https://xkcd.com/1172/)
+
+### Legge di Moore
+
+[Legge di Moore su Wikipedia](https://it.wikipedia.org/wiki/Legge_di_Moore)
+
+> Il numero di transistor in un circuito integrato raddoppia approssimativamente ogni due anni.
+
+Spesso utilizzata per illustrare il tasso con cui le tecnologie a semiconduttori e i chip migliorano nel tempo, la legge di Moore si è dimostrata molto accurata dagli anni Settanta fino alla fine dei Duemila. Più di recente il trend è lievemente cambiato, in parte a causa delle [limitazioni fisiche alla miniaturizzazione delle componenti elettroniche](https://it.wikipedia.org/wiki/Effetto_tunnel) ma tuttavia avanzamenti nel campo della parallelizzazione del calcolo e scoperte potenzialmente rivoluzionarie nel campo delle tecnologie a semiconduttori e nel quantum computing potrebbero portare la legge di Moore a valere anche nei prossimi decenni.
+
+### Legge di Parkinson
+
+[Legge di Parkinson su Wikipedia](https://it.wikipedia.org/wiki/La_legge_di_Parkinson)
+
+> Il lavoro tende ad espandersi fino ad impiegare tutto il tempo disponibile per svolgerlo.
+
+Nel suo contesto originale, questa legge era riferita agli studi sulla gestione della burocrazia. Può essere applicata in ottica pessimistica alle iniziative di sviluppo software, e in sostanza afferma che i team saranno inefficienti fino all'approssimarsi delle deadline e lavoreranno quindi di corsa per rispettare tali deadline rendendole, in un certo senso, arbitrarie.
+
+Combinando la legge di Parkinson con la [Legge di Hofstadter](#legge-di-hofstadter), si ottiene una vista ancora più pessimistica: il lavoro tenderà ad espandersi fino ad impiegare tutto il tempo disponibile per svolgerlo e *in ogni caso richiederà più tempo di quanto previsto*.
+
+Vedi anche:
+
+- [Legge di Hofstadter](#legge-di-hofstadter)
+
+### Effetto di Ottimizzazione Prematura
+
+[Ottimizzazione Prematura su WikiWikiWeb](http://wiki.c2.com/?PrematureOptimization)
+
+> L'ottimizzazione prematura è la radice di ogni male.
+>
+> [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en)
+
+
+Nella sua pubblicazione [Programmazione Strutturata con clausole Go To](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements),
+Donald Knuth scrisse: "I programmatori perdono un'enormità di tempo a preoccuparsi delle performance delle sezioni non critiche dei loro programmi, e i tentativi di efficientarle hanno in realtà un forte impatto negativo durante il debugging e la manutenzione. Dovremmo dimenticarci dei piccoli efficientamenti, che impattano circa il 97% del tempo di esecuzione: **l'ottimizzazione prematura è la radice di ogni male**. Di contro non dovremmo mai lasciarci sfuggire l'occasione di migliorare quel critico 3% del tempo di esecuzione."
+
+L'_Ottimizzazione Prematura_ può essere definita (in termini meno coloriti) come l'attività di efficientamento fatta prima di avere evidenza della sua necessità.
+
+### Legge di Putt
+
+[Legge di Putt su Wikipedia](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat)
+
+> Il mondo della tecnologia è dominato da due tipi di persone: coloro che comprendono ciò che non gestiscono e coloro che gestiscono ciò che non comprendono.
+
+La Legge di Putt è spesso accompagnata dal Corollario di Putt:
+
+> Ogni gerarchia tecnica, genera un'inversione delle competenze con il passare del tempo.
+
+Queste frasi suggeriscono che, a causa di svariati criteri di selezione e trend con cui i gruppi di lavoro si organizzano, ci sarà un certo numero di persone di vasta esperienza con ruoli tecnici operativi e un certo numero di ruoli manageriali che non sono in grado di comprendere la complessità e le sfide del contesto lavorativo che sono chiamati a gestire. Ciò si spiega con fenomeni come il [Principio di Peter](#TODO) o [La Legge di Dilbert](#TODO).
+
+Tuttavia, è corretto specificare che Leggi come queste sono una grande generalizzazione e si applicano ad _alcuni_ tipi di organizzazione e non ad altri.
+
+Vedi anche:
+
+- [Principio di Peter](#TODO)
+- [Legge di Dilbert](#TODO).
+
+
+### Legge di Conservazione della Complessità (Legge di Tesler)
+
+[Legge di Conservazione della Complessità su Wikipedia](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity)
+
+Le Legge dice che in ogni sistema esiste un certo livello di complessità che non può essere ridotto.
+
+Parte della complessità di un sistema è introdotta "inavvertitamente" ed è conseguenza della struttura imperfetta, degli errori o semplicemente di una modellizzazione errata del problema da risolvere. La complessità involontaria può essere ridotta (o eliminata). Tuttavia, parte della complessità è "intrinseca" ed è conseguenza della complessità inerente al problema da risolvere. Questa complessità può essere spostata ma non eliminata.
+
+Un elemento interessante di questa Legge è che ci dice che anche semplificando l'intero sistema, la complessità intrinseca non viene ridotta ma viene _spostata sull'utente_, che deve di conseguenza interagire in modo più sofisticato con il sistema.
+
+
+### Legge dell'Astrazione Fallata
+
+[La Legge dell'Astrazione Fallata su Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/)
+
+> Tutte le astrazioni non banali sono in qualche modo fallate.
+>
+> ([Joel Spolsky](https://twitter.com/spolsky))
+
+Questa legge afferma che le astrazioni generalmente usate in informatica per semplificare l'uso di sistemi complessi, in certe situazioni, lasceranno "trapelare" il dettaglio dei sistemi sottostanti facendo così funzionare l'astrazione in modo inaspettato.
+
+Un esempio è l'apertura di un file e la lettura del suo contenuto. L'API di un file system è un'_astrazione_ del kernel di sistema, il quale è a sua volta un'astrazione dei processi fisici di modifica dei dati su un disco magnetico (o su una memoria flash nel caso di SSD). Nella maggior parte dei casi, l'astrazione di considerare il file come uno stream di dati binario funzionerà senza problemi. Tuttavia, nel caso di un disco magnetico, la lettura sequenziale dei dati sarà *significativamente* più veloce di un accesso random (per via dell'overhead dovuto ai page fault), ma nel caso di un disco SSD tale overhead non è presente. I dettagli implementativi dell'astrazione dovranno dunque essere compresi se si vuole gestire questo comportamento (ad esempio, i file indice di un database sono strutturati per ridurre l'overhead dell'accesso random), l'astrazione "fallata" lascerà trapelare questi dettagli che possono essere di interesse per il programmatore.
+
+L'esempio di cui sopra può diventare anche più complesso quando vengono introdotte astrazioni _multiple_. Il sistema operativo Linux consente di accedere file attraverso una rete, rappresentandoli localmente come file "normali". Questa astrazione "farà acqua" se la rete verrà interrotta. Se uno sviluppatore trattasse questi file come file "noemali", senza considerare il fatto che possono essere soggetti alla latenza e alle interruzioni della rete, la soluzione sviluppata avrà un baco.
+
+L'articolo che descrive questa Legge suggerisce che un'eccessiva fiducia nelle astrazioni, combinata con una scarsa comprensione del sistema sottostante, di fatto in alcuni casi _aumenta_ la complessità del problema da risolvere.
+
+Vedi anche:
+
+- [Legge di Hyrum (Legge delle Interfacce Implicite)](#legge-di-hyrum-legge-delle-interfacce-implicite)
+
+Esempi dal mondo reale:
+
+- [Partenza lenta di Photoshop](https://forums.adobe.com/thread/376152) - problema incontrato nel passato su Photoshop, che a volta impiegava minuti per avviarsi. Sembra che il problema fosse che all'avvio Photoshop leggeva informazioni sulla stampante di default. Tuttavia, se la stampante era una stampante di rete, questa lettura poteva impiegare un tempo molto lungo. L'_astrazione_ per cui la stampante di rete era presentata al sistema esattamente come una stampante locale causava quindi una situazione di estrema lentezza per gli utenti in condizioni di rete lenta.
+
+### Legge di Irrilevanza
+
+[Legge di Irrilevanza su Wikipedia](https://en.wikipedia.org/wiki/Law_of_triviality)
+
+La Legge afferma che i team di lavoro tendono a dedicare molto più tempo e attenzione a dettagli irrilevanti o legati alla cosmesi del lavoro piuttosto che alle questioni serie e sostanziali.
+
+Il tipico esempio fittizio usato per illustrare la Legge è quello di un comitato incaricato di approvare i piani per un impianto nucleare, che passa più tempo a discutere i dettagli del ripostiglio delle biciclette che a discutere il ben più importante design dell'impianto stesso. Può essere difficile a volte dare il giusto contributo quando si discute di argomenti grandi e complessi senza avere una preparazione o esperienza adeguata in merito. Tuttavia, le persone vogliono in genere mostrarsi attive nel collaborare fornendo input di valore. Da qui la tendenza a concentrarsi troppo sul dettaglio spiccio, che può essere discusso facilmente, ma non ha necessariamente rilevanza.
+
+L'esempio fittizio ha portato all'utilizzo del termine "ripostiglio delle biciclette" come metafora della perdita di tempo sui dettagli di poca rilevanza. 
+
+### Filosofia Unix
+
+[La Filosofia Unix su Wikipedia](https://it.wikipedia.org/wiki/Filosofia_Unix)
+
+La Filosofia Unix predica che le componenti software debbano essere piccole e mirate a implementare bene un solo scopo. Ciò rende più semplice costruire sistemi mediante composizione di unità piccole, semplici e ben definite, piuttosto che mediante composizione di programmi grossi, complessi e multi-purpose.
+
+Le moderne prassi come le "Architettura a Microservizi" possono essere viste come applicazioni di questa Filosofia, per cui i servizi sono piccoli e focalizzati sul fare una cosa specifica, consentendo la creazione di comportamenti complessi mediante composizione di mattoni più semplici.
+
+### Il modello Spotify
+
+[Il modello Spotify su Spotify Labs](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/)
+
+Il modello Spotify è un approccio alla strutturazione del lavoro e dell'azienda che è stato reso popolare da Spotify. In questo modello, i team di lavoro sono organizzati attorno alle features invece che alle tecnologie.
+
+Il modello Spotify rende inoltre popolari i concetti di Tribù, Gilda, Capitolo, che sono altre componenti della struttura organizzativa.
+
+
+### Legge di Wadler
+
+[Legge di Wadler su wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law)
+
+> Nella progettazione di qualsiasi linguaggio, il tempo totale impiegato a discutere un elemento di questa lista è proporzionale a 2 elevato alla potenza corrispondente alla posizione dell'elemento:
+> 
+> 0. Semantica
+> 1. Sintassi
+> 2. Sintassi lessicale
+> 3. Sintassi lessicale dei commenti
+> 
+> (In breve: per ogni ora spesa a discutere della semantica, 8 ore saranno spese sulla sintassi dei commenti).
+
+Similmente alla [Legge di Irrilevanza](#legge-di-irrilevanza), la Legge di Wadler afferma che nel design di un linguaggio di programmazione il tempo speso sulla discussione della struttura del linguaggio è sproporzionatamente alto se comparato con l'importanza delle feature discussa.
+
+Vedi anche:
+
+- [Legge di Irrilevanza](#legge-di-irrilevanza)
+
+## Principi
+
+I Principi sono in generale usabili come linee guida per il design.
+
+
+### Principio di Pareto (regola dell'80-20)
+
+[Il Principio di Pareto su Wikipedia](https://it.wikipedia.org/wiki/Principio_di_Pareto)
+
+> Nella vita, la maggior parte delle cose non è distribuita equamente.
+
+Il Principio di Pareto suggerisce che in alcuni casi, la maggior parte dei risultati è effetto di una minoranza degli input
+
+- l'80% di un software è scrivibile nel 20% del tempo totale allocato per la sua scrittura (di contro, il 20% del codice, ossia le parti più complicate di esso, impiega l'80% del tempo)
+- il 20% dell'effort produce l'80% del risultato
+- il 20% del lavoro genera l'80% della revenue
+- il 20% dei bachi genera l'80% dei crash
+- il 20% delle features soddisfa l'80% degli utenti
+
+Negli anni Quaranta l'ingegnere Americano-Rumeno Dr.Joseph Juran, che è riconosciuto universalmente come il padre del controllo di qualità, [iniziò ad applicare il Principio di Pareto alla quality assurance](https://en.wikipedia.org/wiki/Joseph_M._Juran)
+
+Questo Principio è anche noto come: Regola dell'80/20, Legge dei Pochi ma Vitali e il Principio della Scarsità dei Fattori.
+
+Esempi dal mondo reale:
+
+- Nel 2002 la Microsoft riferì che sistemando il 20% dei bachi nella lista tra i più segnalati vennero sistemati l'80% degli errori e dei crash correlati su Windows e Office ([Riferimento](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)).
+
+### Principio di Robustezza (Legge di Postel)
+
+[Il Principio di Robustezza su Wikipedia](https://en.wikipedia.org/wiki/Robustness_principle)
+
+> Siate conservativi nelle vostre azioni, ma liberali in ciò che accettate dagli altri.
+
+Spesso applicato allo sviluppo di applicazioni lato server, questo principio afferma che ciò viene inviato alle terze parti dovrebbe essere il più contenuto e standard possibile, e di contro si dovrebbe accettare anche input non-standard - fintanto che è processabile - in arrivo dalle terze parti.
+
+L'obiettivo di questo principio è la costruzione di sistemi robusti in quanto possono gestire input malformato, a patto che l'intento degli input si possa ancora cogliere. Tuttavia l'accettazione di input malformati pone potenziali implicazioni a livello di sicurezza, soprattutto laddove non si testi a fondo l'ingestione di tali input.
+
+### SOLID
+
+SOLID è un acronimo:
+
+* S: [Principio di Singola Responsabilità](#principio-di-singola-responsabilita)
+* O: [Principio dell'Open Closed](#principio-dell-open-closed)
+* L: [Principio di Sotituzione di Liskov](#principio-di-sostituzione-di-liskov)
+* I: [Principio di Segregazione delle Interfacce](#principio-di-segregazione-delle-interfacce)
+* D: [Principio di Inversione delle Dipendenze](#principio-di-inversione-delle-dipendenze)
+
+These are key principles in [Object-Oriented Programming](#todo). Design principles such as these should be able to aid developers build more maintainable systems.
+
+### Principio di Singola Responsabilità
+
+[Principio di Singola Responsabilità su Wikipedia](https://it.wikipedia.org/wiki/Principio_di_singola_responsabilit%C3%A0)
+
+> Ogni modulo o classe dovrebbe avere una sola responsabilità.
+
+Il primo dei Principi '[SOLID](#solid)'. Afferma che i moduli o le classi software dovrebbero fare una e una sola cosa. In termini più pratici, ciò significa che una piccola modifica ad una feature di un programma dovrebbe richiedere la corrispondente modifica di una sola sua componente. Per esempio, cambiare il modo in cui la complessità di una password viene validata dovrebbe richiedere la modifica di una sola parte del programma.
+
+In teoria, ciò dovrebbe garantire una maggiore robustezza del codice, con maggiore facilità di modifica. Sapere che un componente da cambiare ha una sola responsabilità ne semplifica grandemente il _testing_. Riprendendo l'esempio fatto prima, la modifica del componente che gestisce la validazione della password dovrebbe impattare solo le features di programma che sono correlate con la complessità della password. Di contro, testare un componente che ha svariate responsabilità diventa molto più difficoltoso.
+
+Vedi anche:
+
+- [Object-Oriented Programming](#todo)
+- [SOLID](#solid)
+
+### Principio dell'Open Closed
+
+[Il Principio dell'Open Closed su Wikipedia](https://it.wikipedia.org/wiki/Principio_aperto/chiuso)
+
+> Le entità software dovrebbero essere aperte all'estensione ma chiuse alla modifica.
+
+Il secondo dei Principi '[SOLID](#solid)' afferma che le entità software (classi, moduli, funzioni) dovrebbero incoraggiare la possibilità di _estendere_ il proprio comportamento e scoraggiare la modifica del loro _comportamento esistente_
+
+Ad esempio, si prenda un modulo in grado di trasformare un documento Markdown in HTML. Se il modulo può essere esteso per gestire una nuova feature proposta per il Markdown, senza doverne modificare il funzionamento interno, allora può definirsi aperto all'estensione. Se al contrario il modulo _non_ può essere modificato dai consumer nel modo in cui gestisce le feature correnti di Markdown, allora sarebbe _chiuso_ alla modifica.
+
+Questo Principio è particolarmente rilevante nella programmazione orientata agli oggetti, dove è desiderabile progettare tipi di oggetti facilmente estendibili e il cui comportamento corrente non venga modificato in maniera inaspettata.
+
+Vedi anche:
+
+- [Object-Oriented Programming](#todo)
+- [SOLID](#solid)
+
+### Principio di Sotituzione di Liskov
+
+[Il Principio di Sotituzione di Liskov su Wikipedia](https://it.wikipedia.org/wiki/Principio_di_sostituzione_di_Liskov)
+
+> Deve essere possibile sostituire l'istanza di un tipo con l'istanza di un suo sottotipo senza rompere il codice.
+
+Il terzo dei Principi '[SOLID](#solid)' afferma che se un componente software fà affidamento su un tipo, allora deve essere possibile utilizzare dei suoi sottotipi al suo posto senza causare errori né dover conoscere il dettaglio di quale sottotipo si sta utilizzando.
+
+A titolo di esempio, si immagini di avere un metodo che legge un documento XML da una struttura dati che rappresenta un file. Se il metodo accetta il tipo base 'file' come input, allora qualsiasi tipo derivi da 'file' dovrebbe poter essere utilizzato come input al metodo. Se 'file' supporta la ricerca dalla fine all'inizio e il parser XML usa tale funzione, ma il tipo derivato 'network file' non supporta tale funzione, allora 'network file' violerebbe il Principio.
+
+Il Principio ha particolare rilevanza nella programmazione orientata agli oggetti, dove le gerarchie di tipo devono essere modellizzate con cautela in modo da non generare confusione negli utilizzatori del codice.
+
+Vedi anche:
+
+- [Object-Oriented Programming](#todo)
+- [SOLID](#solid)
+
+### Principio di Segregazione delle Interfacce
+
+[Il Principio di Segregazione delle Interfacce su Wikipedia](https://it.wikipedia.org/wiki/Principio_di_segregazione_delle_interfacce)
+
+> Nessun client dovrebbe dipendere da comportamenti che non usa.
+
+Il quarto dei Principi '[SOLID](#solid)' afferma che i consumer di una componente software non dovrebbero dipendere da funzionalità del componente che non utilizzano.
+
+Ad esempio, si immagini di avere un metodo che legge un documento XML da una struttura dati che rappresenta un file. Deve limitarsi a leggere i byte e a muoversi avanti/indietro sul file. Se tale metodo deve essere aggiornato perchè una caratteristica della struttura del file cambia in modo scorrelato (es. modifica al modello di permessi di sicurezza sul file), allora il Principio non viene rispettato. Sarebbe meglio a questo punto che il file implementasse un'interfaccia 'seekable-stream' e che il lettore XML la sfruttasse.
+
+Il Principio ha particolare rilevanza nella programmazione orientata agli oggetti, dove interfacce, gerarchie e tipi astratti sono utilizzati per [minimizzare l'accoppiamento](#todo) tra le diverse componenti software. Il [Duck typing](#todo) è un meccanismo che implementa il Principio attraverso l'eliminazione delle interfacce esplicite.
+
+Vedi anche:
+
+- [Object-Oriented Programming](#todo)
+- [SOLID](#solid)
+- [Duck Typing](#todo)
+- [Disaccoppiamento](#todo)
+
+### Principio di Inversione delle Dipendenze
+
+[Il Principio di Inversione delle Dipendenze su Wikipedia](https://it.wikipedia.org/wiki/Principio_di_inversione_delle_dipendenze)
+
+> I moduli di alto livello non dovrebbero dipendere dalle implementazioni di basso livello.
+
+
+
+
+Il quinto dei Principi '[SOLID](#solid)' afferma che le componenti di alto livello che orchestrano l'esecuzione non dovrebbero conoscere i dettagli delle loro dipendenze.
+
+Ad esempio, si immagini di avere un programma che legge metadati da un sito web. Si potrebbe pensare che le componenti principali debbano conoscere dell'esistenza di un componente adibito al download del contenuto di una pagina web e anche di un componente in grado di leggere i metadati. Tenendo conto dell'inversione delle dipendenze, il componente principale dipenderebbe solo su un componente astratto in grado di recuperare byte e su un componente astratto in grado di leggere i metadati da uno stram di byte. Il componente principale dunque non dovrebbe sapere nulla di TCP/IP, HTTP, HTML, etc.
+
+Questo Principio è complesso perchè sembra 'invertire' le dipendenze attese di un sistema (da qui il suo nome). In pratica, ciò significa anche che ci deve essere un componente orchestrante di alto livello per assicurare la corretta implementazione dei tipi astratti sui quali si dipende (eg. nell'esempio di prima, _qualcosa_ deve in ogni caso fornire al componente lettore di metadati un file downloader su HTTP e un lettore di metatag HTML). Questo porta all'uso di pattern come l'[Inversione del Controllo](#todo) e l'[Iniezione delle Dipendenze](#todo).
+
+Vedi anche:
+
+- [Object-Oriented Programming](#todo)
+- [SOLID](#solid)
+- [Inversione del Controllo](#todo)
+- [Iniezione delle Dipendenze](#todo)
+
+### Principio DRY
+
+[Il Principio DRY su Wikipedia](https://it.wikipedia.org/wiki/Don%27t_repeat_yourself)
+
+> Ogni elemento di conoscenza deve avere una sola, non ambigua, autorevole rappresentazione all'interno di un sistema.
+
+DRY è l'acronimo dell'inglese _Don't Repeat Yourself_ (Non Reinventare la Ruota). Questo Principio mira ad aiutare gli sviluppatori a ridurre le duplicazioni nel codice e mantenere le informazioni in un solo punto, e fu citato nel 1999 da Andrew Hunt e Dave Thomas nel libro [The Pragmatic Programmer](https://it.wikipedia.org/wiki/The_Pragmatic_Programmer)
+
+> Il contrario di DRY è _WET_ (Write Everything Twice or We Enjoy Typing - Scrivi Tutto In Doppio o Adoriamo Scrivere alla Tastiera).
+
+In pratica, se lo stesso elemento informativo si trova duplicato in due (o più) posti differenti, si può usare DRY per fondere insieme gli elementi in un solo posto e riusarlo laddove serva.
+
+Vedi anche:
+
+- [The Pragmatic Programmer](https://it.wikipedia.org/wiki/The_Pragmatic_Programmer)
+
+### YAGNI
+
+[YAGNI su Wikipedia](https://it.wikipedia.org/wiki/You_aren%27t_gonna_need_it)
+
+Si tratta dell'acronimo dell'inglese _**Y**ou **A**ren't **G**onna **N**eed **I**t_ (_Non Ne Avrai Bisogno_)
+
+> Scrivi una porzione di codice sempre e solo quando ne hai un bisogno reale, e mai quando sai solo prevedere il suo uso futuro.
+>
+> ([Ron Jeffries](https://twitter.com/RonJeffries)) (co-fondatore dell'eXtreme Programming e autore del libro "Extreme Programming Installed")
+
+Questo Principio dell'_Extreme Programming_ (XP) afferma che gli sviluppatore dovrebbero implementare solo le funzionalità che sono necessarie sulla base dei requisiti immediati ed evitare la tentazione di predire il futuro implementando funzionalità di cui potrebbero avere bisogno più avanti.
+
+L'aderenza a questo principio dovrebbe ridurre nella codebase la quantità di codice non utilizato, evitando così di sprecare tempo ed effort per sviluppare funzionalità che non portano valore immediato.
+
+Vedi anche:
+
+- [Reading List: Extreme Programming Installed](#reading-list)
+
+
+## Reading List
+
+Se avete trovato questi concetti interessanti, potrebbero interessarvi anche i seguenti libri.
+
+- [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Tratta i principi fondamentali dell'Extreme Programming.
+- [The Mythical Man Month - Frederick P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - Un grande classico sull'ingegneria del software. La [Legge di Brooks](#legge-di-brooks) è un tema centrale del libro.
+- [Gödel, Escher, Bach: An Eternal Golden Braid - Douglas R. Hofstadter.](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - Questo libro è difficile da classificare. La [Legge di Hofstadter](#legge-di-hofstadter) è presa da qui.
+
+## TODO
+
+Salve! Se vi trovate qui è perchè avete cliccato sul link ad un argomento che ancora non è stato trattato, mi dispiace - questa pagina è un cantiere aperto!
+
+Sentitevi liberi di [Segnalare un Problema](https://github.com/dwmkerr/hacker-laws/issues), richiedere più dettaglio o [Aprire una Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) per proporre la vostra definizione dell'argomento.

translations/pt-BR.md

@@ -0,0 +1,479 @@
+# 💻📖 hacker-laws
+
+Leis, Teorias, Principios e Padrões que desenvolvedores acham úteis.
+
+- 🇨🇳 [中文 / Versão Chinesa ](https://github.com/nusr/hacker-laws-zh) - Obrigado [Steve Xu](https://github.com/nusr)!
+- 🇰🇷 [한국어 / 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)!
+- 🇹🇷 [Türkçe / Versão Turka](https://github.com/umutphp/hacker-laws-tr) - Obrigado [Umut Işık](https://github.com/umutphp)
+
+---
+
+<!-- vim-markdown-toc GFM -->
+
+* [Introdução](#introdução)
+* [Leis](#leis)
+    * [Lei De Amdahl](#lei-de-amdahl)
+    * [Lei de Brook](#lei-de-brook)
+    * [Lei de Conway](#lei-de-conway)
+    * [Número de Dunbar](#número-de-dunbar)
+    * [Navalha de Hanlon](#navalha-de-hanlon)
+    * [Lei de Hofstadter](#lei-de-hofstadter)
+    * [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 Moore](#lei-de-moore)
+    * [Lei de Parkinson](#lei-de-parkinson)
+    * [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)
+    * [A lei das Abstrações gotejantes](#a-lei-das-abstrações-gotejantes)
+    * [The Law of Triviality](#the-law-of-triviality)
+    * [The Unix Philosophy](#the-unix-philosophy)
+    * [The Spotify Model](#the-spotify-model)
+    * [Wadler's Law](#wadlers-law)
+* [Principles](#principles)
+    * [The Pareto Principle (The 80/20 Rule)](#the-pareto-principle-the-8020-rule)
+    * [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)
+    * [YAGNI](#yagni)
+* [Lista de Livros](#lista-de-livros)
+* [Em Progresso](#em-progresso)
+
+<!-- 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.
+
+<!--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! <!-->
+
+❗: 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!!
+
+### Lei De Amdahl
+
+[Lei de Amdahl na Wikipedia](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.
+
+O diagrama abaixo mostra alguns exemplos de melhoria na velocidade:
+
+![Diagram: Lei de Amadhl](../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)*
+
+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_.
+
+### Lei de Brook
+
+[Lei de Brooks na Wikipeia](https://en.wikipedia.org/wiki/Brooks%27s_law)
+
+
+> 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, adcionando mais pessoas atrasa ainda mais essa entrega. Brooke assume que essa afirmação é uma generalização excessiva, entretanto, o principal motivo para isso acontecer é dado pelo simples fato de adicionar pessoas requer um gasto com comunicação e construção de novos recursos para a equipe suportar novos membros. Logo, a curto prazo esse investimento não tem um retorno. Também existem tarefas que não podem ser dividias, portanto adicionar mais pessoas não vai fazer ela ser concluida mais rápido. 
+
+"Nove mulheres não podem parir uma criança em um mês" e "Dois pilotos não fazem o carro ir mais rápido" são frases relacionadas a Lei de Brooke, principalmente porque algumas tarefas nao podem ser divididas.
+
+
+Esse é um tema central do livro'[The Mythical Man Month](#lista-de-livros)'.
+
+Veja também:
+
+- [Death March](#em-progresso)
+- [Livro: The Mythical Man Month](#lista-de-livros)
+
+### Lei de Conway
+
+[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.
+
+Veja também:
+
+- [Modelo do Spotify](#modelo-spotify)
+
+### 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.
+
+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.
+
+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.
+
+Veja também:
+
+- [Lei de Conwy](#lei-de-conway)
+
+### Navalha de Hanlon
+
+[Navalha de Hanlon na wikipedia](https://en.wikipedia.org/wiki/Hanlon%27s_razor)
+
+> Nunca atribua à malícia aquilo que é adequadamente explicado por estupidez.
+>
+> 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.
+
+
+
+### Lei de Hofstadter
+
+[Lei de Hofstadter na Wikipedia](https://en.wikipedia.org/wiki/Hofstadter%27s_law)
+
+
+> Sempre leva mais tempo do que esperado, mesmo quando se leva em conta a lei do Hofstadter.
+>
+> Douglas Hofstadter
+
+Você já deve ter ouvido sobre essa lei quando se fala em estimar tempo para fazer algo. Quando se fala em desenvolvimento de software parece obvio que nós tendemos a não sermos muitos precisos em estimar quando tempo levará para entregar alguma coisa.
+
+This is from the book '[Gödel, Escher, Bach: An Eternal Golden Braid](#lista-de-livros)'.
+
+
+### 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.
+>
+> Roy Amara
+
+O Ciclo Hype é uma representação visual da empolgação e desenvolvimento da tecnologia ao longo do tempo, originalmente produzida por Gartner.
+![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)*
+
+Em curto prazo, o cilco sugere que acontece uma explosão de empolgação a cerca de uma nova tecnologia e seu impácto em potencial. Equipes geralmente entram juntas nessas tecnlogias de forma rápida e em alguns casos ficam desapontados com os resutados. Uma das possíveis causas para isso é o fato da tecnologia em questão não ser madura o suficiente, ou aplicações do mundo real não estão totalmente prontas. Depois de um certo tempo, a capacidade da tecnologia aumenta e oportunidades práticas para uso dela aumentam, as equipes finalmente podem ser produtivos. A citação de Amara resume isso de forma sucinta - "Nós tendemos a superestimar os efeitos da tecnologia em curto prazo e subestimar os efeitos a longo prazo".
+
+
+### Lei de Hyrum (A lei de interfaces implicitas)
+
+[Lei de Hyrum site](http://www.hyrumslaw.com/)
+
+
+>Com um número suficientes de clientes de uma API,
+>não importa a sua pré-condição no contato:
+>todos os comportamentos observáveis do seu sistema
+>serão dependentes de alguém.
+>
+> (Hyrum Wright)
+
+A lei de Hyrum sugere que quando voce tem um número muito grande de consumidores de uma API, todos os comportamentos dessa API(mesmo aqueles que não estão definidos como parte de um contrato público) eventualmente irão dependender de outra parte do sistema, ou outra API. Um exemplo trivial pode ser elementos não funcionais, como o tempo de resposta de uma API. Um exemplo mais sutil pode ser os consumidores que estão confiando em aplicar um regex a uma mensagem de erro para determinar o _tipo_ de erro de uma API. Mesmo que o contrato público da API não especifique nada sobre o conteúdo da mensagem, indicando que os usuários devem usar um código de erro associado, alguns usuários podem usar a mensagem e alterar a mensagem essencialmente interrompe a API para esses usuários.
+
+Veja Também:
+
+- [XKCD 1172](https://xkcd.com/1172/)
+
+### Lei de Moore
+
+[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.
+
+
+Até meados de 1965 não havia nenhuma previsão real sobre o futuro do hardware, quando Gordon E. Moore fez sua profecia, na qual o número de transistores dos chips teria um aumento de 100%, pelo mesmo custo, a cada período de 18 meses. Essa profecia tornou-se realidade e acabou ganhando o nome de Lei de Moore.
+
+Esta lei serve de parâmetro para uma elevada gama de dispositivos digitais, além das CPUs. Na verdade, qualquer chip está ligado a lei de Gordon E. Moore, até mesmo o CCD de câmeras fotográficas digitais (sensor que capta a imagem nas câmeras nuclear; ou CNCL, sensores que captam imagens nas câmeras fotográficas profissionais).
+
+Esse padrão continuou a se manter, e não se espera que pare até, no mínimo, 2021.
+
+### 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.
+
+### Lei de Putt
+
+[Lei de Putt na wikipedia](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat)
+
+> Tecnologia é dominada por dois tipos de pessoa. Aqueles que entendem o que não gerenciam e aqueles que gerenciam o que não entendem.
+
+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)
+
+Veja também:
+
+- [O Principio de Peter](#em-progresso)
+- [Lei de Dilbert](#em-progresso).
+
+
+### A lei da Conservação de 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.
+
+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
+
+[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.
+
+An example might be loading a file and reading its contents. The file system APIs are an _abstraction_ of the lower level kernel systems, which are themselves an abstraction over the physical processes relating to changing data on a magnetic platter (or flash memory for an SSD). In most cases, the abstraction of treating a file like a stream of binary data will work. However, for a magnetic drive, reading data sequentially will be *significantly* faster than random access (due to increased overhead of page faults), but for an SSD drive, this overhead will not be present. Underlying details will need to be understood to deal with this case (for example, database index files are structured to reduce the overhead of random access), the abstraction 'leaks' implementation details the developer may need to be aware of.
+
+The example above can become more complex when _more_ abstractions are introduced. The Linux operating system allows files to be accessed over a network but represented locally as 'normal' files. This abstraction will 'leak' if there are network failures. If a developer treats these files as 'normal' files, without considering the fact that they may be subject to network latency and failures, the solutions will be buggy.
+
+The article describing the law suggests that an over-reliance on abstractions, combined with a poor understanding of the underlying processes, actually makes dealing with the problem at hand _more_ complex in some cases.
+
+See also:
+
+- [Hyrum's Law](#hyrums-law-the-law-of-implicit-interfaces)
+
+Real-world examples:
+
+- [Photoshop Slow Startup](https://forums.adobe.com/thread/376152) - an issue I encountered in the past. Photoshop would be slow to startup, sometimes taking minutes. It seems the issue was that on startup it reads some information about the current default printer. However, if that printer is actually a network printer, this could take an extremely long time. The _abstraction_ of a network printer being presented to the system similar to a local printer caused an issue for users in poor connectivity situations.
+
+### The Law of Triviality
+
+[The Law of Triviality on Wikipedia](https://en.wikipedia.org/wiki/Law_of_triviality)
+
+This law suggests that groups will give far more time and attention to trivial or cosmetic issues rather than serious and substantial ones.
+
+The common fictional example used is that of a committee approving plans for nuclear power plant, who spend the majority of their time discussing the structure of the bike shed, rather than the far more important design for the power plant itself. It can be difficult to give valuable input on discussions about very large, complex topics without a high degree of subject matter expertise or preparation. However, people want to be seen to be contributing valuable input. Hence a tendency to focus too much time on small details, which can be reasoned about easily, but are not necessarily of particular importance.
+
+The fictional example above led to the usage of the term 'Bike Shedding' as an expression for wasting time on trivial details.
+
+### The Unix Philosophy
+
+[The Unix Philosophy on Wikipedia](https://en.wikipedia.org/wiki/Unix_philosophy)
+
+The Unix Philosophy is that software components should be small, and focused on doing one specific thing well. This can make it easier to build systems by composing together small, simple, well-defined units, rather than using large, complex, multi-purpose programs.
+
+Modern practices like 'Microservice Architecture' can be thought of as an application of this law, where services are small, focused and do one specific thing, allowing complex behaviour to be composed of simple building blocks.
+
+### The Spotify Model
+
+[The Spotify Model on Spotify Labs](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/)
+
+The Spotify Model is an approach to team and organisation structure which has been popularised by 'Spotify'. In this model, teams are organised around features, rather than technologies.
+
+The Spotify Model also popularises the concepts of Tribes, Guilds, Chapters, which are other components of their organisation structure.
+
+### Wadler's Law
+
+[Wadler's Law on wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law)
+
+> In any language design, the total time spent discussing a feature in this list is proportional to two raised to the power of its position.
+> 
+> 0. Semantics
+> 1. Syntax
+> 2. Lexical syntax
+> 3. Lexical syntax of comments
+> 
+> (In short, for every hour spent on semantics, 8 hours will be spent on the syntax of comments).
+
+Similar to [The Law of Triviality](#the-law-of-triviality), Wadler's Law states what when designing a language, the amount of time spent on language structures is disproportionately high in comparison to the importance of those features.
+
+See also:
+
+- [The Law of Triviality](#the-law-of-triviality)
+
+## Principles
+
+Principles are generally more likely to be guidelines relating to design.
+
+### The Pareto Principle (The 80/20 Rule)
+
+[The Pareto Principle on Wikipedia](https://en.wikipedia.org/wiki/Pareto_principle)
+
+> Most things in life are not distributed evenly.
+
+The Pareto Principle suggests that in some cases, the majority of results come from a minority of inputs:
+
+- 80% of a certain piece of software can be written in 20% of the total allocated time (conversely, the hardest 20% of the code takes 80% of the time)
+- 20% of the effort produces 80% of the result
+- 20% of the work creates 80% of the revenue
+- 20% of the bugs cause 80% of the crashes
+- 20% of the features cause 80% of the usage
+
+In the 1940s American-Romanian engineer Dr. Joseph Juran, who is widely credited with being the father of quality control, [began to apply the Pareto principle to quality issues](https://en.wikipedia.org/wiki/Joseph_M._Juran).
+
+This principle is also known as: The 80/20 Rule, The Law of the Vital Few and The Principle of Factor Sparsity.
+
+Real-world examples:
+
+- In 2002 Microsoft reported that by fixing the top 20% of the most-reported bugs, 80% of the related errors and crashes in windows and office would become eliminated ([Reference](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)).
+
+### The Robustness Principle (Postel's Law)
+
+[The Robustness Principle on Wikipedia](https://en.wikipedia.org/wiki/Robustness_principle)
+
+> Be conservative in what you do, be liberal in what you accept from others.
+
+Often applied in server application development, this principle states that what you send to others should be as minimal and conformant as possible, but you should be aim to allow non-conformant input if it can be processed.
+
+The goal of this principle is to build systems which are robust, as they can handle poorly formed input if the intent can still be understood. However, there are potentially security implications of accepting malformed input, particularly if the processing of such input is not well tested.
+
+### 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.
+
+### The Single Responsibility Principle
+
+[The Single Responsibility Principle on Wikipedia](https://en.wikipedia.org/wiki/Single_responsibility_principle)
+
+> Every module or class should have a single responsibility only.
+
+The first of the '[SOLID](#solid)' principles. This principle suggests that modules or classes should do one thing and one thing only. In more practical terms, this means that a single, small change to a feature of a program should require a change in one component only. For example, changing how a password is validated for complexity should require a change in only one part of the program.
+
+Theoretically, this should make the code more robust, and easier to change. Knowing that a component 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.
+
+See also:
+
+- [Object-Oriented Programming](#todo)
+- [SOLID](#solid)
+
+### The Open/Closed Principle
+
+[The Open/Closed Principle on Wikipedia](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle)
+
+> Entities should be open for extension and closed for modification.
+
+The second of the '[SOLID](#solid)' principles. This principle states that entities (which could be classes, modules, functions and so on) should be able to have their behaviour _extended_, but that their _existing_ behaviour should not be able to be modified.
+
+As a hypothetical example, imagine a module which is able to turn a Markdown document into HTML. If the module could be extended to handle a newly proposed markdown feature, without modifying the module internals, then it would be open for extension. If the module could _not_ be modified by a consumer so that how existing Markdown features are handled, then it would be _closed_ for modification.
+
+This principle has particular relevance for object-oriented programming, where we may design objects to be easily extended, but would avoid designing objects which can have their existing behaviour changed in unexpected ways.
+
+See also:
+
+- [Object-Oriented Programming](#todo)
+- [SOLID](#solid)
+
+### The Liskov Substitution Principle
+
+[The Liskov Substitution Principle on Wikipedia](https://en.wikipedia.org/wiki/Liskov_substitution_principle)
+
+> It should be possible to replace a type with a subtype, without breaking the system.
+
+The third of the '[SOLID](#solid)' principles. This principle states that if a component relies on a type, then it should be able to use subtypes of that type, without the system failing or having to know the details of what that subtype is.
+
+As an example, imagine we have a method which reads an XML document from a structure which represents a file. If the method uses a base type 'file', then anything which derives from 'file' should be able to be used in the function. If 'file' supports seeking in reverse, and the XML parser uses that function, but the derived type 'network file' fails when reverse seeking is attempted, then the 'network file' would be violating the principle.
+
+This principle has particular relevance for object-oriented programming, where type hierarchies must be modeled carefully to avoid confusing users of a system.
+
+See also:
+
+- [Object-Oriented Programming](#todo)
+- [SOLID](#solid)
+
+### The Interface Segregation Principle
+
+[The Interface Segregation Principle on Wikipedia](https://en.wikipedia.org/wiki/Interface_segregation_principle)
+
+> No client should be forced to depend on methods it does not use.
+
+The fourth of the '[SOLID](#solid)' principles. This principle states that consumers of a component should not depend on functions of that component which it doesn't actually use.
+
+As an example, imagine we have a method which reads an XML document from a structure which represents a file. It only needs to read bytes, move forwards or move backwards in the file. If this method needs to be updated because an unrelated feature of the file structure changes (such as an update to the permissions model used to represent file security), then the principle has been invalidated. It would be better for the file to implement a 'seekable-stream' interface, and for the XML reader to use that.
+
+This principle has particular relevance for object-oriented programming, where interfaces, hierarchies and abstract types are used to [minimise the coupling](#todo) between different components. [Duck typing](#todo) is a methodology which enforces this principle by eliminating explicit interfaces.
+
+See also:
+
+- [Object-Oriented Programming](#todo)
+- [SOLID](#solid)
+- [Duck Typing](#todo)
+- [Decoupling](#todo)
+
+### The Dependency Inversion Principle
+
+[The Dependency Inversion Principle on Wikipedia](https://en.wikipedia.org/wiki/Dependency_inversion_principle)
+
+> High-level modules should not be dependent on low-level implementations.
+
+The fifth of the '[SOLID](#solid)' principles. This principle states that higher level orchestrating components should not have to know the details of their dependencies.
+
+As an example, imagine we have a program which read metadata from a website. We would assume that the main component would have to know about a component to download the webpage content, then a component which can read the metadata. If we were to take dependency inversion into account, the main component would depend only on an abstract component which can fetch byte data, and then an abstract component which would be able to read metadata from a byte stream. The main component would not know about TCP/IP, HTTP, HTML, etc.
+
+This principle is complex, as it can seem to 'invert' the expected dependencies of a system (hence the name). In practice, it also means that a separate orchestrating component must ensure the correct implementations of abstract types are used (e.g. in the previous example, _something_ must still provide the metadata reader component a HTTP file downloader and HTML meta tag reader). This then touches on patterns such as [Inversion of Control](#todo) and [Dependency Injection](#todo).
+
+See also:
+
+- [Object-Oriented Programming](#todo)
+- [SOLID](#solid)
+- [Inversion of Control](#todo)
+- [Dependency Injection](#todo)
+
+### The DRY Principle
+
+[The DRY Principle on Wikipedia](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)
+
+> Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
+
+DRY is an acronym for _Don't Repeat Yourself_. This principle aims to help developers reducing the repetition of code and keep the information in a single place and was cited in 1999 by Andrew Hunt and Dave Thomas in the book [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+
+> The opposite of DRY would be _WET_ (Write Everything Twice or We Enjoy Typing).
+
+In practice, if you have the same piece of information in two (or more) different places, you can use DRY to merge them into a single one and reuse it wherever you want/need.
+
+See also:
+
+- [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+
+### 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_.
+
+> Always implement things when you actually need them, never when you just foresee that you need them.
+>
+> ([Ron Jeffries](https://twitter.com/RonJeffries)) (XP co-founder and author of the book "Extreme Programming Installed")
+
+This _Extreme Programming_ (XP) principle suggests developers should only implement functionality that is needed for the immediate requirements, and avoid attempts to predict the future by implementing functionality that might be needed later.
+
+Adhering to this principle should reduce the amount of unused code in the codebase, and avoid time and effort being wasted on functionality that brings no value.
+
+See also:
+
+- [Reading List: Extreme Programming Installed](#reading-list)
+
+
+## Lista de 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) - 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.
+
+## Em Progresso
+
+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. 

translations/tr.md

@@ -0,0 +1,726 @@
+# 💻📖 hacker-laws
+
+Programcıların faydalı bulacağı yasalar, teoriler, prensipler ve desenler.
+
+- 🇨🇳 [中文 / Çince İçin](https://github.com/nusr/hacker-laws-zh) - Teşekkürler [Steve Xu](https://github.com/nusr)!
+- 🇮🇹 [Italyanca için](https://github.com/csparpa/hacker-laws-it) - Teşekkürler [Claudio Sparpaglione](https://github.com/csparpa)!
+- 🇰🇷 [한국어 / Korece İçin](https://github.com/codeanddonuts/hacker-laws-kr) - Teşekkürler [Doughnut](https://github.com/codeanddonuts)!
+- 🇷🇺 [Русская версия / Rusça İçin](https://github.com/solarrust/hacker-laws) - Teşekkürler [Alena Batitskaya](https://github.com/solarrust)!
+- 🇹🇷 [Türkçe / Turkçe İçin](https://github.com/umutphp/hacker-laws-tr) - Teşekkürler [Umut Işık](https://github.com/umutphp)
+- 🇧🇷 [Brasileiro / Brezilyaca İçin](./translations/pt-BR.md) - Teşekkürler [Leonardo Costa](https://github.com/LeoFC97)
+- 🇪🇸 [Castellano / İspanyolca İçin](./translations/es-ES.md) - Teşekkürler [Manuel Rubio](https://github.com/manuel-rubio)
+
+Bu projeyi beğendiniz mi? Lütfen [sponsor olmayı](https://github.com/sponsors/dwmkerr) düşünün!
+
+---
+
+<!-- vim-markdown-toc GFM -->
+
+- [Giriş](#introduction)
+- [Yasalar](#laws)
+    - [Amdahl Yasası](#amdahls-law)
+    - [Kırık Camlar Teorisi](#k%C4%B1r%C4%B1k-camlar-teorisi)
+    - [Brooks Yasası](#brooks-law)
+    - [Conway Yasası](#conways-law)
+    - [Cunningham Yasası](#cunninghams-law)
+    - [Dunbar Sayısı](#dunbars-number)
+    - [Gall Yasası](#galls-law)
+    - [Goodhart Yasası](#goodharts-law)
+    - [Hanlon'un Usturası](#hanlons-razor)
+    - [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)
+    - [Metcalfe Yasası](#metcalfes-law)
+    - [Moore Yasası](#moores-law)
+    - [Murphy Yasası / Sod  Yasası](#murphys-law--sods-law)
+    - [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)
+    - [Sızdıran Soyutlamalar Yasası](#the-law-of-leaky-abstractions)
+    - [Önemsizlik Yasası](#the-law-of-triviality)
+    - [Unix Felsefesi](#the-unix-philosophy)
+    - [Spotify Modeli](#the-spotify-model)
+    - [Wadler Yasası](#wadlers-law)
+    - [Wheaton Yasası](#wheatons-law)
+- [Prensipler](#principles)
+    - [Dilbert Prensibi](#the-dilbert-principle)
+    - [Pareto Prensibi (80/20 Kuralı)](#the-pareto-principle-the-8020-rule)
+    - [Peter Prensibi](#the-peter-principle)
+    - [Dayanıklılık Prensibi (Postel Yasası)](#the-robustness-principle-postels-law)
+    - [SOLID](#solid)
+    - [Tek Sorumluluk Prensibi](#the-single-responsibility-principle)
+    - [Açık/Kapalı Prensibi](#the-openclosed-principle)
+    - [Liskov Yerine Geçme Prensibi](#the-liskov-substitution-principle)
+    - [Arayüz Ayrım Prensibi](#the-interface-segregation-principle)
+    - [Bağımlılığın Ters Çevrilmesi](#the-dependency-inversion-principle)
+    - [DRY Prensibi](#the-dry-principle)
+    - [KISS prensibi](#the-kiss-principle)
+    - [YAGNI](#yagni)
+    - [Dağıtık Sistemlerin Yanılgıları](#the-fallacies-of-distributed-computing)
+- [Ek Kaynaklar](#reading-list)
+- [Katkıda Bulunmak İçin](#katk%C4%B1)
+- [TODO](#todo)
+
+<!-- vim-markdown-toc -->
+
+## Giriş
+
+İnsanların geliştirme hakkında konuşurken tartıştıkları birçok yasa var. Bu depo, en yaygın olanlardan bazılarının referanslarını ve özetini barındırır. Katkıda bulunmak için PR açıp gönderebilirsiniz!
+
+❗: Bu depo yasaların, prensiplerin ve modellerin bilgi vermek amaçlı açıklamalarını içerir ve hiçbirini *savunma* amacı gütmez. Bunların hangisinin uygulanıp uygulanmayacağı tamamen tartışma konusudur ve yapılan işe bağlıdır..
+
+## Yasalar
+
+Tek tek başlayalım!
+
+### Amdahl Yasası
+
+[Wikipedia Amdahl Yasası](https://en.wikipedia.org/wiki/Amdahl%27s_law)
+
+> Amdahl Yasası kaynakları artırarak bir hesaplama işleminin *olası* hızlanma miktarını hesaplayan bir formülü tanımlar. Genellikle paralel işleme hesaplarında kullanılır ve işlemci sayısının artırılmasının programın paralelleştirilebilme kapasitesine bağlı olarak etkisinin doğru şekilde saplanmasını sağlar.
+
+En güzel şu örnekle anlatılabilir. Bir programın iki bölümden oluştuğunu düşünelim. Bölüm A sadece tek işlemci ile çalıştırılabilir. Bölüm B ise paralelleştirilebilecek şekilde yazılmış. Bu durumda bu programı çok işlemci ile çalıştırdığımızda Bölüm B'de oluşacak kadar bir kazanım sağlayabiliriz. Bölüm A'da her hangi bir katkı olamayacaktır.
+
+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">
+
+*(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)*
+
+Diyagramdaki örneklerden görüldüğü üzere, eğer bir programın sadece %50'si paralelleştirilebiliyorsa 10 işlemciden sonra işlemci eklemek hızda gözle görünür bir artış sağlamıyor ama %95 paralelleştirilebilen bir programda 1000 işlemciden sonra bile işlemci eklemenin hızı artırdığı gözlenebilir.
+
+[Moore Yasasında](#moores-law) söylenen artışın azalma eğiliminde olması ve aynı zamanda işlemci hızının artışında da ivme kaybı olması, paralelleştirilebilme özelliğini performans artışında anahtar duruma getirdi. Grafik programlama bu konuda en belirgin örnek. Shader tabanlı modern işleme ile pixel ve fragmanların paralel olarak render edilebilmesi sayesinde modern grafik kartlarında binlerce işlemci çekirdeği olabiliyor.
+
+Ek kaynaklar:
+
+- [Brooks Yasası](#brooks-law)
+- [Moore Yasası ](#moores-law)
+
+### Kırık Camlar Teorisi
+
+[Wikipedia'da Kırık Camlar Teorisi](https://en.wikipedia.org/wiki/Broken_windows_theory)
+
+Kırık Camlar Teorisi, gözle görülebilir suç belirtilerinin (ya da ortamın  bakımsızlığının) daha ciddi suçlara (ya da ortamın daha da bozulmasına) yol açtığını göstermektedir.
+
+Bu teori, yazılım geliştirmeye şu şekilde uygulanabilir; düşük kalite kodun (veya [Teknik Borcun](#TODO)) varlığı kaliteyi geliştirme çabalarının göz ardı edilebileceği veya önemsenmeyeceği algısına yol açabileceği ve dolayısıyla düşük kalite koda sebep olabileceğidir. Bu etki zamanla kalitenin daha çok azalmasına neden olur.
+
+Ek kaynaklar:
+
+- [Teknik Borç](#yapmak)
+
+Örnekler:
+
+- [Pragmatik Programlama: Yazılım Entropisi](https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy)
+- [Kodlama Kabusu: Kırık Camlar Teorisi](https://blog.codinghorror.com/the-broken-window-theory/)
+- [Açık Kaynak: Eğlenceli Programlama - Kırık Camlar Teorisi](https://opensourceforu.com/2011/05/joy-of-programming-broken-window-theory/)
+
+### Brooks Yasası
+
+[Wikipedia'da Brooks Yasası](https://en.wikipedia.org/wiki/Brooks%27s_law)
+
+> Gecikmesi kesinleşmiş projeye yeni insan kaynağı eklemek projeyi daha da geciktirir.
+
+Bu yasa, gecikmiş bir projeyi hızlandırmak için ek insan kaynağı koymanın projeyi daha geciktireceğini iddia ediyor. Brook'a göre bunun gereksiz bir sadeleştirme olduğu kesin. Yeni katılanların adapte edilmesi ve iletişim karmaşası hemen etkisini göstererek hızın yavaşlamasına sebep olur. Ayrıca, yapılacak işlerin birçoğu genellikle daha küçük parçalara bölünemez ve birden fazla kaynak bu işlerin yapılması için kullanılmaz. Bu durum beklenen artışın sağlanmaması ile sonuçlanır.
+
+Meşhur "Dokuz kadın ile 1 ayda doğum sağlanamaz" deyimi bu yasanın en pratik anlatımıdır. Bazı işlerin bölünemediği veya paralelleştirilemediği gerçeğini unutmamak lazım.
+
+'[The Mythical Man Month](#reading-list)' adlı kitabın ana konularından biri budur.
+
+Ek kaynaklar:
+
+- [Death March](#todo)
+- [Reading List: The Mythical Man Month](#reading-list)
+
+### Conway Yasası
+
+[Wikipedia'da Conway Yasası](https://en.wikipedia.org/wiki/Conway%27s_law)
+
+Conway yasası der ki; üretilen sistemler kendilerini üreten organizasyonun teknik sınırlarını yansıtır. Bu yasa daha çok organizasyon değişiklikleri sırasında dikkate alınır. Eğer bir organizasyon birbirinden bağımsız küçük birimlerden oluşuyorsa üretilen yazılımlar da buna uygun olacaktır. Eğer bu organizasyon servis odaklı dikey yapılandırılmışsa, yazılımlar bunu yansıtacaktır.
+
+Ek kaynaklar:
+
+- [Spotify Modeli](#the-spotify-model)
+
+### Cunningham Yasası
+
+[Wikipedia'da Cunningham Yasası](https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham's_Law)
+
+> İnternette doğru cevabı almanın en iyi yolu, soru sormak değil, yanlış olan cevabı yazmaktır.
+
+Steven McGeady'ye göre, Ward Cunningham, 1980'lerin başında ona tavsiye olarak “İnternette doğru cevabı almanın en iyi yolu, bir soru sormak değil, yanlış olan cevabı yazmaktır” dedi. McGeady bunu Cunningham kanunu olarak adlandırdı, ancak Cunningham bu sahipliği bunun "yanlış bir alıntı" olduğunu nitelendirerek reddetti. Her ne kadar orjinalinde Usenet'teki etkileşimlerle ilgili olsa da, yasa diğer çevrimiçi toplulukların nasıl çalıştığını açıklamak için kullanılmıştır (örneğin, Wikipedia, Reddit, Twitter, Facebook).
+
+Ek kaynaklar:
+
+- [XKCD 386: "Duty Calls"](https://xkcd.com/386/)
+
+### Dunbar Sayısı
+
+[Wikipedia'da Dunbar Sayısı](https://en.wikipedia.org/wiki/Dunbar%27s_number)
+
+"Dunbar'ın sayısı, bir kişinin istikrarlı bir sosyal ilişkide bulunabileceği kişilerin sayısının kavramsal sınırıdır - bu ilişki bireyin ilişkide olduğu her bir kişinin kim olduğunu ve her bir kişinin diğer bir kişiler ile ilişkisini bildiği ilişkidir." Sayının tam değeri konusunda bir anlaşmazlık vardır. "... [Dunbar] insanların ancak 150 kişilik ilişkiler istikrarlı bir şekilde bulunabileceğini söylemiş."... Dunbar sayıyı daha sosyal bir bağlam içine koydu, "sayıyı bir barda içki içmeye davet edildiğinizde sıkılmadan ya da utanmadan kabul edebileceğiniz kişi sayısı olarak değerlendirdi". Bu da 100 ile 250 arasındaki bir sayı olarak düşünülebilir.
+
+Kişiler arası insani ilişkilerde olduğu gibi, insanlarla kod arasındaki ilişki de sürüdürülebilmek için çaba gerektirir. Karmaşık projelerle karşılaştığımızda ya da bu projeleri yönetmek sorunda kaldığımızda, projeyi ölçekleyebilmek için eğilimlere, politikalara ve modellenmiş prosedürlere yaslanmaya çalışırız. Dunbar sayısını sadece çalışan sayısı büyüdüğünde değil, takımın harcayacağı emeğin kapsamını belirlerken ya da sistemdeki lojistik ek yükün modellenmesine ve otomatikleştirilmesine yardımcı olmak için takımlara yatırım yaparken de göz önünde bulundurulmalıdır. Bir başka mühendislik bağlamında düşünürsek, bu sayı müşteri destek sisteminde nöbetçi olunurken sorumluluğunu alabileceğiniz proje/ürün sayısını belirlerken de rehber olabilir.
+
+Ek kaynaklar:
+
+- [Conway Yasası](#conways-law)
+
+### 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.
+> ([John Gall](https://en.m.wikipedia.org/wiki/John_Gall_(author)))
+> ([John Gall](https://en.m.wikipedia.org/wiki/John_Gall_(author)))
+> ([John Gall](https://en.m.wikipedia.org/wiki/John_Gall_(author)))
+
+Gall Yasası der ki, çok karmaşık sistemleri *tasarlamaya* çalışmak her zaman başarısızlıkla sonuçlanır. Bu tür sistemlerin ilk denemede başarılı olmaları çok nadir görülür ama genellikle basit sistemlerden evrilirler.
+
+En klasik örnek günümüzdeki internettir.  Şu an çok karmaşık bir sistemdir.  Aslında başlangıçta sadece akademik kurumlar arası içerik paylaşımı olarak tanımlanmıştı. Bu tanımı karşılamada çok başarılı oldu ve zamanla gelişerek bugünkü karmaşık halini aldı.
+
+Ek kaynaklar:
+
+- [KISS (Keep It Simple, Stupid)](#the-kiss-principle)
+
+### Goodhart Yasası
+
+[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.
+> *Charles Goodhart*
+> *Charles Goodhart*
+
+Ayrıca şu şekilde de ifade edilir:
+
+> 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.
+
+Gerçek dünyadan örnekler:
+
+- "Asert" olmadan yazılan testler, ölçümün amacının iyi test edilmiş bir yazılım oluşturmak olmasına rağmen sadece kod kapsamı beklentisini karşılar.
+- Yazılan satır sayısının gösterdiği geliştirici performans puanı haksız yere şişirilmiş kod tabanına yol açar.
+
+Ek kaynaklar:
+
+- [Goodhart Yasası: Yanlış Şeyleri Ölçmek Ahlaksız Davranışları Nasıl Yönlendirir?](https://coffeeandjunk.com/goodharts-campbells-law/)
+- [Sorunsuz bir yazılım dünyasında Dilbert](https://dilbert.com/strip/1995-11-13)
+
+### Hanlon'un Usturası
+
+[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.
+> 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.
+
+### 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.
+> (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.
+
+'[Gödel, Escher, Bach: An Eternal Golden Braid](#reading-list)' adlı kitaptan bir alıntı.
+
+Ek kaynaklar:
+
+- [Reading List: Gödel, Escher, Bach: An Eternal Golden Braid](#reading-list)
+
+### Hutber Yasası
+
+[Wikipedia'da Hutber Yasası ](https://en.wikipedia.org/wiki/Hutber%27s_law)
+
+> İyileştirme, bozulma anlamına da gelir.
+> ([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.
+
+Örneğin, bir servisin cevap verme zamanında bir geliştirme yapılıp hızlandırılırsa bu durum süreçteki diğer aşamalarda kapasite ve çıktı artışına sebep olabilir. Bu da sistemin diğer taraflarını olumsuz etkileyebilir.
+
+### Hype Döngüsü ve Amara Yasası
+
+[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.
+> (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)
+
+*(Resmin Kaynağı: Jeremykemp tarafından İngilizce Wikipeda'da, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)*
+
+Kısaca anlatmak gerekirse, bu döngü her yeni teknolojinin ilk zamanlarında teknolojinin kendisi ve olası etkisi üzerinde bir heyecan dalgası oluştuğunu iddia ediyor. Ekipler yeni teknolojiler hemen kullanmaya çalışıyorlar ve genelde kendilerini sonuçtan memnun olmamış bir halde buluyorlar. Bu ya teknolojinin henüz olgunlaşmamış olmasından, ya da uygulamanın tam anlamıyla gerçekleşmemiş olmasından olabilir. Belirli bir süre geçtikten sonra, teknolojinin yeterliliği ve pratik kullanım alanları artar ve ekipler daha üretken olmaya başlar. Roy Amara'nın sözü bu durumu en özlü şekilde toparlıyor diyebiliriz - "Bir teknolojinin kısa vadede oluşacak etkisini abartıp, uzun vadede oluşacak etkisini hafife alıyoruz".
+
+### Hyrum Yasası (Arabirimlerin Örtülü Hukuku)
+
+[Hyrum Yasası Web Sitesi](http://www.hyrumslaw.com/)
+
+> Belli sayıda kullanıcıya ulaştığında, servis sözleşmesinde ne demiş olduğunuzdan bağımsız olarak ürününüzün ya da sisteminizin bütün gözlemlenebilir davranışları artık üçüncü kişilere göre şekillenecektir.
+> (Hyrum Wright)
+
+Hyrum Yasası göre, eğer bir API'nin *oldukça büyük sayılabilecek sayıda kullanıcısı* olduğunda, artık bütün sonuçlar ve davranışlar (API sözleşmesinde belirtilmemiş olsalar bile) kullanıcılara göre şekillenecektir. Buna bir örnek olarak bir API'nin tepki süresi olabilir. Daha kapsamlı bir örnek olarak kullanıcıların bir regex ile dönen cevap metninin içinden hatanın *tipini* ayıkladıkları bir senaryoyu düşünelim. API sözleşmesinde bu cevap metinleri ile ilgili bir şey belirtilmemiş olmasına ve kullanıcıların hata kodunu kullanmalarını belirtilmesine rağmen, cevap metnini değiştirmeniz *bazı* kullanıcıların metni kullanmalarından dolayı hata ile karşılaşmalarına sebep olacaktır.
+
+Ek kaynaklar:
+
+- [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
+- [XKCD 1172](https://xkcd.com/1172/)
+
+### Metcalfe Yasası
+
+[Wikipedia'da Metcalfe Yasası](https://en.wikipedia.org/wiki/Metcalfe's_law)
+
+> Ağ teorisinde, bir sistemin değeri yaklaşık olarak sistemin kullanıcı sayısının karesi ile orantılı olarak büyür.
+
+Bu yasa, bir sistem içindeki muhtemel çift bağlantıların sayısına dayanmaktadır ve [Reed Yasası](#reeds-law) ile yakından ilgilidir. Odlyzko ve diğerleri, hem Reed Yasası hem de Metcalfe Yasası'nın, insan bilişinin ağ etkileri üzerindeki sınırlarını hesaba katmayarak sistemin değerini abarttığını öne sürerler; [Dunbar Sayısı'na](#dunbars-number) bakınız.
+
+Ek kaynaklar:
+
+- [Reed Yasası](#reeds-law)
+- [Dunbar Sayısı](#dunbars-number)
+
+### Moore Yasası
+
+[Wikipedia'da Moore Yasası](https://en.wikipedia.org/wiki/Moore%27s_law)
+
+> Entegre devre içerisindeki transistörlerin sayısı yaklaşık olarak iki yılda bir ikiye katlanır.
+
+Çoğu zaman yarı-iletken ve çip teknolojisinin gelişim hızını tahmin etmek için kullanılan Moore yasasının, 1970'lerden 2000'lerin sonlarına doğru oldukça doğru olduğu biliyoruz. Son yıllarda, [komponentlerin küçülmesinde fiziksel sınırlara](https://en.wikipedia.org/wiki/Quantum_tunnelling) ulaşıldığı için bu tahminlemenin tutmadığını da söyleyebiliriz. Ama paralelleştirmede uzmanlaşılması ve yarı-iletken teknolojilerindeki devrim potansiyelindeki değişiklikler Moore Yasası'nın yakın zamanda tekrar doğrulanacağını tahminler yapabileceğini düşünebiliriz.
+
+### Murphy Yasası / Sod Yasası
+
+[Wikipedia'da Murphy Yasası](https://en.wikipedia.org/wiki/Murphy%27s_law)
+
+> Eğer bir işin kötü gitme ihtimali varsa mutlaka kötü gider.
+
+İsmini [Edward A. Murphy, Jr](https://en.wikipedia.org/wiki/Edward_A._Murphy_Jr.)'dan alan *Murphy Yasası* der ki eğer bir işin kötü gitme ihtimali varsa mutlaka kötü gider.
+
+Bu programcılar arasında çok kullanılan bir atasözüdür. Geliştirme yaparken, test ederken ya da canlı sistemlerde çoğunlukla hep beklenmedik sorunlar olur. Bu durum  (İngiltere'de yaygın kullanılan) *Sod Yasası* ile de ilişkilendirilebilir:
+
+> Eğer bir işin kötü gitme ihtimali varsa, olabilecek en kötü zamanda kötüye gidecektir.
+
+Bu iki 'yasa' daha çok espri amaçlı kullanılır. Bunun yanında, [*Doğrulama Önyargısı*](#TODO) ve [*Seçim Tarafgirliği*](#TODO) gibi olgular bu yasaların insanlar tarafında çok fazla vurgulanmasına sebep olabilir (işler yolundayken hiçbirşeye dikkat etmeyiz, ama bunun yanında sorunlar yaşanınca herşey göze batmaya başlar ve tartışılır).
+
+Ek kaynaklar:
+
+- [Doğrulama Önyargısı](#TODO)
+- [Seçim Tarafgirliği](#TODO)
+
+### Parkinson Yasası
+
+[Wikipedia'da Parkinson Yasası](https://en.wikipedia.org/wiki/Parkinson%27s_law)
+
+> Bir iş, daima, bitirilmesi için kendisine ayrılan sürenin hepsini kapsayacak şekilde uzar.
+
+Orijinal bağlamında, bu kanun bürokrasi alanındaki çalışmalara dayanıyordu. Kötümser bir bakış açısıyla yazılım geliştirme girişimleri için de söylenebilir. Şöyle ki ekipler genelde proje bitiş tarihi yaklaşana kadar düşük verimde çalışırlar, bitiş tarihi yaklaştıkça bitirmek için yoğun bir çaba içine girerler ve sonuç olarak aslında bitiş tarihini tutturmuş olurlar.
+
+Bu yasa ile [Hofstadter Yasası](#hofstadters-law) birleştirilirse, daha kötümser bir yasaya ulaşılır. Bir iş bitirilmesi için harcanması gereken zamanı kapsar ve *her zaman gecikir*.
+
+Ek kaynaklar:
+
+- [Hofstadter Yasası](#hofstadters-law)
+
+### Olgunlaşmamış Optimizasyon Etkisi
+
+[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.
+> [(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."
+
+Aslında, *olgunlaşmamış optimizasyonu* ihtiyacımızın ne olduğunu bilmeden yapılan optimizasyon olarak tanımlayabiliriz (daha basit kelimelerle).
+
+### Putt Yasası
+
+[Wikipedia'da Putt Yasası](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat)
+
+> Teknolojide iki tür insan egemendir, yönetmedikleri şeyleri anlayanlar ve anlamadıkları şeyleri yönetenler.
+
+Putt yasasını çoğunlukla Putt sonucu takip eder:
+
+> Her teknik hiyerarşi, zaman içinde bir yetkinlik dönüşümü geliştirir.
+
+Bu iki cümle der ki grupların organiza olma şekillerindeki seçim kıstasları ve eğilimleri yüzünden bir zaman sonra teknik organizasyonun çalışma seviyelerinde bir grup yetenekli insan varken yönettikleri işin karmaşıklığından ve zorluklarından bihaber bir grup insan da yönetim kademelerini işgal edecektir. Bu durum [Peter Prensibi](#the-peter-principle) ya da [Dilbert Prensibi](#the-dilbert-principle) ile de açıklanabilir.
+
+Bununla birlikte, bunun gibi yasaların çok büyük genellemeler olduğu ve *bazı* organizasyon türleri için geçerli olabileceği gibi başkaları için geçerli olmayacağı unutulmamalıdır.
+
+Ek kaynaklar:
+
+- [Peter Prensibi](#the-peter-principle)
+- [Dilbert Prensibi](#the-dilbert-principle)
+
+### Reed Yasası
+
+[Wikipedia'da Reed Yasası](https://en.wikipedia.org/wiki/Reed's_law)
+
+> Büyük ağların, özellikle sosyal ağların kullanımı, ağın boyutuna katlanarak ölçeklenir.
+
+Bu yasa, programın faydasının olası katılımcı veya ikili bağlantı sayısından daha hızlı olan olası alt grup sayısı olarak ölçeklendiği grafik teorisine dayanmaktadır. Odlyzko ve diğerleri, Reed Yasası'nın, insan bilişinin ağ etkileri üzerindeki sınırlarını hesaba katarak sistemin yararını abarttığını öne sürerler; [Dunbar Sayısı'na](#dunbars-number) bakınız.
+
+Ek kaynaklar:
+
+- [Metcalfe Yasası](#metcalfes-law)
+- [Dunbar Sayısı](#dunbars-number)
+
+### Karmaşıklığın Korunması Yasası (Tesler Yasası)
+
+[Wikipedia'da Karmaşıklığın Korunması Yasası](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity)
+
+Bu yasa der ki, her sistemde kesinlikle ayıklanamayacak bir miktarda karmaşıklık vardır.
+
+Bir sistem ve yazılımdaki karmaşıklıkların bazıları dikkatsizlik veya yanlışlıktan ortaya çıkar. Bu kötü kurgulanmış yapının, herhangi bir dikkatsizliğin, ya da problemin kötü modellenmesinin sonucu olabilir. Bu tarz karmaşıklıklar giderilebilir ve sistemden ayıklanabilir. Bunun yanında, bazı karmaşıklıklar sistemin gerçekleridir yani sistemin çözmeye çalıştığı problemin doğası gereği ortaya çıkarlar. Bu tarz karmaşıklıklar sistem içinde farklı yerlere taşınabilirler ama sistemden ayıklanmazlar.
+
+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*.
+
+### 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.
+> ([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.
+
+Dosya açma ve okuma işlemlerini örneklemek için kullanabiliriz. Dosya sistemi arayüzleri altta yeralan çekirdek sistemlerinin bir *soyutlamasıdır*, ki çekirdek sistemleri de aslında manyetik plakalardaki (fash disk ya da SDD) veriyi fiziksel olarak değiştiren işlemlerin soyutlamasıdır. Çoğu durumda, bir dosyayı ikili sistemdeki verilerin akışı olarak soyutlamak işe yarar. Manyetik sürücüler sıralı okuma yapıldığında rastgele erişimli sürücülere göre *daha* hızlıdır (sayfalama hatalarının artmasından dolayı) ama bu durum SDD sürücülerle karşılaştırmada geçerli değildir. Bu durumun üstesinden gelmek için, detayların altında yatan bilgileri (yani geliştiricinin bilmesi gereken uygulama detaylarını) soyutlamanın sızdırıyor olacağı dikkate alınmalıdır.
+
+Yukarıda verdiğimiz örnek *daha fazla* soyutlanma göz önünde bulundurulursa daha da karmaşıklaşabilir. Linux işletim sistemi dosyalara bir ağ üzerinden erişilmesine olanak sağlıyor ama bu dosyalar sanki yerel dosyalarmış gibi gösterilir. Bu soyutlama da eğer bir network sorunu olursa sızıntı oluşturur. Eğer bir uygulama geliştirici bu tür dosyaları normal dosyalarmış gibi düşünerek geliştirme yaparsa, ağızda oluşan herhangi bir gecikme ya da sorun çözümü sorunlu hale getirecektir.
+
+Yasa savunmaya çalıştığı durum, herhangi bir soyutlamaya çok fazla güvenmenin alta yatan işlemleri de tam anlamamayla birleşince çözülmeye çalışılan problemin çoğunlukla *daha da* karmaşıklaşması ile sonuçlanacağıdır.
+
+Ek kaynaklar:
+
+- [Hyrum Yasası](#hyrums-law-the-law-of-implicit-interfaces)
+
+Gerçek dünyadan örnekler:
+
+- [Photoshop'taki yavaş açılma problemi](https://forums.adobe.com/thread/376152): Photoshop bir zamanlar çok yavaş açılırdı, hatta bazen açılması dakikalar sürerdi. Sorunun sebebi program her başlangıçta ön tanımlı yazıcı ile ilgili belli bilgileri çekmeye çalışması olarak gözüküyordu. Eğer yazıcı bir ağ yazıcısıysa açılma daha da uzun sürüyordu. Ağ yazıcılarının yerel yazıcıları gibi *soyutlanması* kullanıcılara bu kötü deneyimi yaşatmış oldu.
+
+### Önemsizlik Yasası
+
+[Wikipedia'da Önemsizlik Yasası](https://en.wikipedia.org/wiki/Law_of_triviality)
+
+Bu yasa diyor ki, ekipler önemsiz ve kozmetik sorunlara ciddi ve önemli sorunlara göre daha fazla zaman harcarlar.
+
+En çok kullanılan kurgu örnek nükleer enerji reaktörünü onaylayacak olan komitenin reaktörün genel tasarımını onaylama zamanından çok bisiklet parkının tasarımını onaylamak için zaman harcamasıdır. Çok büyük ve karmaşık konularla ilgili o alanda bir eğitime, tecrübeye ve hazırlığa sahip olmadan kayda değer yorum getirmek zordur. İnsanlar genelde değerli katkılar verdiklerinin görülmesini isterler. Dolayısıyla insanlar kolayca katkı verebilecekleri gerekli ve önemli olmasa bile küçük detaylara odaklanma eğilimi gösterirler.
+
+Bu kurgu örnek 'Bike Shedding' diye bir deyimin yaygınlaşmasına sebep olmuştur. Türkçe'deki 'pire için yorgan yakmak' ya da 'attığın taş ürküttüğün kurbağaya değsin' gibi deyimlere benzer. Alternatif bir terim 'Yak Shaving' de kullanılmaktadır.
+
+### Unix Felsefesi
+
+[Wikipedia'da Unix Felsefesi](https://en.wikipedia.org/wiki/Unix_philosophy)
+
+Unix felsefesi şöyle özetlenebilir; bir yazılım parçası olabildiğince küçük olmalı ve sadece bir işi yapmaya odaklanmalıdır. Bu felsefeye uymak sistemleri büyük, karmaşık ve çok amaçlı programlarla oluşturmak yerine küçük, basit ve iyi tanımlanmış parçalardan daha kolayca oluşturmayı sağlar.
+
+Modern yaklaşımlardan biri olan 'Mikro-service Mimarisi' de bu felsefenin uygulaması olarak düşünülebilir. Çünkü bu mimari ile servislerin küçük, amaç odaklı ve tek bir iş yapacak şekilde geliştirilmesi ve karmaşık yapıların küçük basit bloklar halinde oluşturulması hedefleniyor.
+
+### Spotify Modeli
+
+[Spotify Modeli, Spotify Labs](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/)
+
+Spotify Modeli Spotify'daki uygulamasından dolayı popüler olmuş ekip ve organizasyon yapıları için yeni bir yaklaşımdır. Model basitçe ekiplerin teknolojilere göre değil de özellikler etrafında organize edilmesidir.
+
+Spotify Modeli kabileler (Tribes), birlikler (Guilds) ve kısımlar (Chapter) gibi organizasyon yapısında kullanılacak öğeleri de yaygın hale getirdi.
+
+### Wadler Yasası
+
+[Wadler Yasası, wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law)
+
+> Herhangi bir programlama dilini tasarlarken, aşağıdaki listedeki herhangi bir özelliği tartışmak için harcanan zaman iki üzeri özelliğin listeki sırası ile doğru orantılıdır.
+> 1. Semantik
+> 2. Genel sözdizimi
+> 3. 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.)
+
+[Ö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.
+
+Ek kaynaklar:
+
+- [Önemsizlik Yasası](#the-law-of-triviality)
+
+### Wheaton Yasası
+
+[Link](http://www.wheatonslaw.com/)
+
+[Resmi Gün](https://dontbeadickday.com/)
+
+> Öküzlük yapmayın.
+> *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.
+
+## Prensipler
+
+Prensiplerin genellikle tasarıma ilişkin rehberlerdir.
+
+### 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.
+> *Scott Adams*
+
+Scot Adams (Dilbert çizgi dizisinin yazarı) [Peter prensibinden](#the-peter-principle) esinlenerek ortaya atılmış bir yönetim kavramıdır. Dilbert prensibine göre yetenekli olmayan çalışanlar yönetim kadorlarına dopru yükseltilirler ki üretime verecekleri zarar aza indirilsin. Adams bunu ilk olarak 1995'te Wall Street Journal'da yazdığı bir makalede açıkladı daha sonra ise 1996'da yazdığı [Dilbert Prensibi](#reading-list) adlı kitabında detaylandırdı.
+
+Ek kaynaklar:
+
+- [Peter Prensibi](#the-peter-principle)
+- [Putt Yasası](#putts-law)
+
+### Pareto Prensibi (80/20 Kuralı)
+
+[Wikipedia'da Pareto Prensibi](https://en.wikipedia.org/wiki/Pareto_principle)
+
+> Hayattaki çoğu şey eşit dağılmaz.
+
+Pareto Prensibi der ki, çıktıların önemli bir çoğunluğu girdilerin çok azı tarafından oluşturulur:
+
+- Bir yazılımın 80%'i harcanan zamanın %20'sinde yazılır (bir başka deyişle, kodun en zor %20'lik bölümü haracanan zamanın %80'inde yazılır)
+- Harcanan eforun %20'si sonucun %80'ini oluşturur
+- Yapılan işin %20'si gelirin %80'ini oluşturur
+- Koddaki hataların %20'si sistem sorunlarının %80'ini oluşturur
+- Özelliklerin %20'si hizmetin %80'ini oluşturur
+
+1940'lı yıllarda Romanya kökenli Amerikalı mühendis Dr. Joseph Juran, kendisi kalite kontrolün babası olarak nitelendirilir, [kalite kontrol sorunlarında Pareto Prensibini kullanmaya başladı](https://en.wikipedia.org/wiki/Joseph_M._Juran).
+
+
+Bu prensip aynı zamanda 80/20 Kuralı (The Law of the Vital Few and The Principle of Factor Sparsity) olarak da bilinir.
+
+Gerçek dünyadan örnekler:
+
+- 2002'de Microsoft en çok rapor edilen hataların üstten %20'sini çözünce kullanıcıların yaşadığı sorunların %80'inin çözüldüğünü gözlemlemiş ([Referans](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)).
+
+### Peter Prensibi
+
+[Wikipedia'da Peter Prensibi](https://en.wikipedia.org/wiki/Peter_principle)
+
+> Hiyerarşideki insanlar “yetersizlik seviyelerine” göre yükselme eğilimindedir.
+> *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.
+
+Bu, temelde farklı bir beceri kümesi gerektirdiğinden özellikle mühendislerle - kariyerine teknik rollerle başlayan ama sonra kariyer değiştirip diğer mühendisleri *yönetmeye* başlayan -  alakalıdır.
+
+Ek kaynaklar:
+
+- [Dilbert Prensibi](#the-dilbert-principle)
+- [Putt Yasası](#putts-law)
+
+### Dayanıklılık Prensibi (Postel Yasası)
+
+[Wikipedia'da Dayanıklılık Prensibi](https://en.wikipedia.org/wiki/Robustness_principle)
+
+> Yaptıklarınızda muhafazakar olun, başkalarından kabul ettiğiniz şeyler konusunda liberal olun.
+
+Genellikle sunucu uygulamaları geliştirirken uygulanabilir. Bu prensip der ki; kendi uygulamanızdan dışarıya veri gönderirken kılı kırk yararcasına dikkatli olun ama dışardan veri alırken mümkün olabilecek her durumda veriyi kabul etmeye çalışın.
+
+Bu prensibin amacı dayanıklı sistemlere geliştirmektir ve bu sistemler kötü yapılandırılmış girdileri bile anlayabildikleri durumda işleyebilmeliler. Bunun güvenlik açısından kötü amaçlı ve yeterince kontrol edilmemiş girdileri kabul etmek anlamına gelebileceği için riskli olduğu düşünülebilir. Tabiki bu riskin de göz önünde bulundurulması gerekir.
+
+### SOLID
+
+SOLID aşağıdaki beş prensibin baş harflerinden oluşan bir kısaltmadır;
+
+- S: [Tek Sorumluluk Prensibi - The Single Responsibility Principle](#the-single-responsibility-principle)
+- O: [Açık/Kapalı Prensibi - The Open/Closed Principle](#the-openclosed-principle)
+- L: [Liskov Yerine Geçme Prensibi - The Liskov Substitution Principle](#the-liskov-substitution-principle)
+- I: [Arayüz Ayrım Prensibi - The Interface Segregation Principle](#the-interface-segregation-principle)
+- D: [Bağımlılığın Ters Çevrilmesi - The Dependency Inversion Principle](#the-dependency-inversion-principle)
+
+Bunları [Nesne Tabanlı Proglamlama'nın](#todo) temel prensipleri olarak değerlendirilebilir ve bu prensiplerin programcılara geliştirilebilir ve desteklenebilir sistemler geliştirmelerinde yardımcı oldukları kesindir.
+
+### Tek Sorumluluk Prensibi
+
+[Wikipedia'da Tek Sorumluluk Prensibi](https://en.wikipedia.org/wiki/Single_responsibility_principle)
+
+> Her sistem parçasının ya da programlama sınıfının sadece bir sorumluluğu olmalı.
+
+Bu '[SOLID](#solid)' prensiplerinin ilkidir. Bu prensip der ki her bir sistem parçasının yada programlama sınıfının sadece ama sadece bir sorumluluğu olması gerekir. Daha sade anlatmak gerekirse, bir programdaki sadece bir özelliği etkileyen bir değişiklik sadece o özelliği ilgilendiren parça ya da sınıfta yapılmalı. Örneğin, şifrelerin doğruluğunun kontrolünde bir değiştirme yapılacaksa sadece programın o bölümünde değişiklik yapılmalı.
+
+Teorik olarak, bu prensibe uygun yazılmış kodlar daha sağlam ve değiştirilmesi kolaydır. Sadece tek bir parçanın değiştirildiğine emin olunduğunda değişimi *tesk etmek* de kolay olacaktır. Önceki şifre örneğini düşünürsek, şifrenin zorluk seviyesi değiştirildiğinde sadece şifre ilgili bölümlerin etkilenecektir. Birden fazla sorumluluğu olan bir bölümde olan değişikliğin nereleri etkileceğini hesaplamak daha zordur.
+
+Ek kaynaklar:
+
+- [Nesne Tabanlı Programlama](#todo)
+- [SOLID](#solid)
+
+### Açık/Kapalı Prensibi
+
+[Wikipedia'da Açık/Kapalı Prensibi](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle)
+
+> Her sistem parçası (sınıf, modül, fonksiyon vs) genişletilmeye (türev alınmaya, miras alınma vs) açık olmalı ama değiştirilmeye (modifiye etme) kapalı olmalı.
+
+Bu '[SOLID](#solid)' prensiplerinin ikincisidir ve herhangi bir sistem parçasının *mevcut* davranışının değiştirilememesini ama kullanılarak/türetilerek *genişletilebilmesinin* gerekliliğini savunur.
+
+Örneğin Markdown formatındaki belgeleri HTML formatına çeviren bir modülü düşünelim. Eğer bu modül kendisi değiştirilmeden yeni bir Markdown formatını da işlemesi sağlanacak şekilde geliştirilebiliyorsa, bu modül genişletilmeye açık demektir. Eğer sonradan değiştirilip Markdown formatı işlemesi ile ilgili geliştirme *yapılamıyorsa*, bu modül değiştirilmeye *kapalı* demektir.
+
+
+Bu prensip nesne-tabanlı programlamaya tam uygundur. Şöyle ki, kendi nesne ve sınıflarımızı miras alınarak geliştirmeye uygun ve değiştirmeye ihtiyaç duymayacak şekilde tasarlarsak ve yazarsak nesne-tabanlı programlamaya tam uygun kod yazmış oluruz.
+
+Ek kaynaklar:
+
+- [Nesne Tabanlı Programlama](#todo)
+- [SOLID](#solid)
+
+### Liskov Yerine Geçme Prensibi
+
+[Wikipedia'da Liskov Yerine Geçme Prensibi](https://en.wikipedia.org/wiki/Liskov_substitution_principle)
+
+> Bir sistemde var olan bir özellik kendinden türetilmiş türetilmiş bir özellikle herhangi bir sistemsel soruna sebep olmadan yer değiştirilebilmeli.
+
+'[SOLID](#solid)' prensiplerinin üçüncüsüdür. Bu prensibe göre herhangi bir bileşenin üzerine dayandığı bir özelliği (sınıf vs) o özelliklikten türetilmiş alt özellikle değiştirebilmeliyiz ve bu durumda bir sistem sorununa neden olunmaz ya da alt özelliğin bütün detaylarını bilmeye gerek kalmaz.
+
+Örneğin dosyayı temsil eden bir yapıdan XML verisi okuyan bir metod düşünelim. Eğer bu metod 'dosya' tipini kullanıyorsa, 'dosya' tipinden türeyen bütün tipleri de kullanabilmelidir. Eğer 'dosya' tipi geriye dönük aramayı destekliyorsa ama 'dosya' tipinden türetilmiş 'ağ dosyası' tipi bunu desteklemiyorsa o zaman 'ağ dosyası' tipi bu prensibi ihlal ediyor demektir.
+
+Bu prensip nesne-tabanlı programlamanın bağlı olduğu prensiplerden biridir ve geliştiricilerin kafasını karıştırmamak için sınıf hiyerarşisinin dikkatli tarasarlanması gerektiğini söyler.
+
+Ek kaynaklar:
+
+- [Nesne Tabanlı Programlama](#todo)
+- [SOLID](#solid)
+
+### Arayüz Ayrım Prensibi
+
+[Wikipedia'da Arayüz Ayrım Prensibi](https://en.wikipedia.org/wiki/Interface_segregation_principle)
+
+> Hiçbir kullanıcı/müşteri/istemci, kullanmadığı yöntemlere bağlı kalmamalıdır.
+
+'[SOLID](#solid)' prensiplerinin dördüncüsüdür ve bir bileşenin kullanıcılarının, kullanmadığı bir bileşenin işlevlerine bağımlı olmaması gerektiğini belirtir.
+
+Örnek olarak dosyayı temsil eden bir yapıdan XML verisi okuyan bir metod düşünelim. Bu metod sadece dosyadan byte byte veri okumalı ve dosya içinde ileri ya da geri hareket etmeli. Eğer bu method dosya okuma dışında (dosya izinleri değişimi gibi) herhangi bir özellik değişiminden dolayı güncellenmek zorunda kalınıyorsa bu prensip ihlal edilmiş demektir.
+
+Bu prensip de nesne-tabanlı programlama ile direk ilişkilidir. 'interface' yapıları, sınıf hiyerarşileri ve soyut türler farklı bileşenler arası bağımlığı en aza indirmek için kullanılır. Duck typing de bu prensibi uygulamaya yardımcı olur.
+
+Ek kaynaklar:
+
+- [Nesne Tabanlı Programlama](#todo)
+- [SOLID](#solid)
+- [Duck Typing](#todo)
+- [Ayrışma](#todo)
+
+### Bağımlılığın Ters Çevrilmesi
+
+[Wikipedia'da Bağımlılığın Ters Çevrilmesi](https://en.wikipedia.org/wiki/Dependency_inversion_principle)
+
+> Yüksek seviye modülleri, düşük seviye uygulamalarına bağlı olmamalıdır.
+
+'[SOLID](#solid)' prensiplerin beşincisidir. Bu ilke, daha üst seviye bileşenlerinin bağımlılıklarının ayrıntılarını bilmek zorunda olmadıklarını belirtir.
+
+Örnek olarak bir web sitesinden metadata okuyan bir program düşünelim. Bu programın ana bileşeninin web sitesinden içeriği indiren ve metadayı okuyan bileşenlerinden ne yaptığından haberdar olması gerekir. Eğer bu prensibe uyarsak ana bileşenin byte verisi okuyan ve byte verisinden metada çıkaran soyutlamalara bağımlı olması lazım. Ana bileşenin TCP/IP, HTTP ya da HTML hakında bir detaya hakim olmasına gerek yoktur.
+
+Bu prensip olması gereken bağımlığı tersine çevirdiği düşünebileceğinden (isminden dolayı) biraz karmaşık gelebilir. Pratikte, ayrı bir düzenleme bileşeninin, soyut türlerin doğru uygulamalarının kullanılmasını sağlaması gerektiği anlamına gelir (önceki örnekte, *bir şey* hala meta veri okuyucu bileşenine bir HTTP dosyası indiricisi ve HTML meta etiketi okuyucu sağlamalıdır). Bu prensip aynı zamanda [Kontrolün Ters Çevirilmesi](#todo) ve [Bağımlık Enjeksiyonu](#todo) gibi konularla da bağlantılıdır.
+
+
+Ek kaynaklar:
+
+- [Nesne Tabanlı Programlama](#todo)
+- [SOLID](#solid)
+- [Bağımlılığın Ters Çevrilmesi](#todo)
+- [Bağımlılık Enjeksiyonu](#todo)
+
+### DRY Prensibi
+
+[Wikipedia'da DRY Prensibi](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)
+
+> Her bilgi parçasının bir sistem içinde tek, açık ve net bir temsiline sahip olması gerekir.
+
+*DRY Don't Repeat Yourself* yani Kendini Tekrar Etme deyimin kısaltılmasıdır. İlk olarak Andrew Hunt ve Dave Thomas tarafından [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) kitabında bahsedilmiştir. Bu ilke, geliştiricilere kod tekrarını azaltma ve bilgileri tek bir yerde tutmalarına yardımcı olmayı amaçlamaktadır.
+
+
+> DRY'nin tam tersi *WET* olacaktır (Write Everything Twice (Her Şeyi İki Kez Yaz) We Enjoy Typing (Yazmayı Seviyoruz)).
+
+Uygulamada, aynı bilgi parçasını iki (veya daha fazla) farklı yerde kullanıyorsanız, DRY'yi bunları tek bir tanede birleştirmek ve istediğiniz / ihtiyaç duyduğunuz yerde tekrar kullanmak için kullanabilirsiniz.
+
+Ek kaynaklar:
+
+- [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+
+### KISS prensibi
+
+[Wikipedia'da KISS](https://en.wikipedia.org/wiki/KISS_principle)
+
+> Olabildiğince basit ve aptal (Keep it simple, stupid)
+
+KISS prensibi, çoğu sistemin karmaşıklaştırılmak yerine basit tutulması durumunda en iyi şekilde çalışacağını belirtir; bu nedenle sadelik tasarımda kilit bir amaç olmalı ve gereksiz karmaşıklıktan kaçınılmalıdır. Bu 1960’da ABD Donanması’nda çalışan uçak mühendisi Kelly Johnson ile ilişkilendirilen bir cümle.
+
+Prensip, Johnson'ın bir tasarım mühendisleri ekibine bir avuç el aleti teslim etmesinin öyküsüyle en iyi örneklenmiştir, tasarladıkları jet uçağının sahadaki ortalama bir tamirci tarafından yalnızca bu aletlerle mücadele koşullarında tamir edilebilir olması zorunluluğu ile karşı karşıyadır. Bu nedenle, "aptal" kelimesi mühendislerin kendi yeteneklerini değil, işlerin kırılma şekli ile onları tamir etmek için mevcut araçların karmaşıklığı arasındaki ilişkiyi ifade eder.
+
+Ek kaynaklar:
+
+- [Gall Yasası](#galls-law)
+
+### YAGNI
+
+[Wikipedia'da YAGNI](https://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it)
+
+***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.
+> ([Ron Jeffries](https://twitter.com/RonJeffries)) (XP eş-kurucusu and "Extreme Programming Installed" kitabının yazarı)
+
+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.
+
+Bu ilkeye bağlı kalmak, kod tabanındaki kullanılmayan kod miktarının ve hiçbir değer getirmeyen işlevlerde haracanan zamanın ve çabanın azalmasını sağlayacaktır.
+
+Ek kaynaklar:
+
+- [Reading List: Extreme Programming Installed](#reading-list)
+
+### 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)
+
+*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:
+
+- Ağ güvenilirdir.
+- Gecikme yoktur.
+- Bant genişliği sonsuzdur.
+- Ağ güvenlidir.
+- Topoloji değişmez.
+- Sadece bir tane yönetici vardır.
+- Taşıma maaliyeti sıfırdır.
+- Ağ homojendir.
+
+İlk dört madde 1991'de [Bill Joy](https://en.wikipedia.org/wiki/Bill_Joy) ve [Tom Lyon](https://twitter.com/aka_pugs) tarafından listelenmiştir ve ilk önce [James Gosling](https://en.wikipedia.org/wiki/James_Gosling) tarafından "Ağ Tabanlı Sistemlerin Yanılgıları" olarak sınıflandırılmıştır. [L. Peter Deutsch](https://en.wikipedia.org/wiki/L._Peter_Deutsch)  5., 6. ve 7. yanılgıları ekledi. 90'lı yılların sonlarında Gosling 8. yanılgıyı ekledi.
+
+Grup [Sun Microsystems](https://en.wikipedia.org/wiki/Sun_Microsystems) içinde başlarına gelen olaydan ilham aldı.
+
+Dayanıklı sistemler tasarlarken bu yanılgılar dikkatlice ele alınmalı; bu yanılgılardan herhangi birinin varsayılması, dağıtılmış sistemlerin gerçeklikleri ve karmaşıklıkları ile başa çıkamayan hatalı bir mantığa yol açabilir.
+
+Ek kaynaklar:
+
+- [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)
+
+## Ek Kaynaklar
+
+Bu kavramları ilginç bulduysanız, aşağıdaki kitapların keyfini çıkarabilirsiniz.
+
+- [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Extreme Programming kavramının temel prensiplerini içerir.
+- [The Mythical Man Month - Frederick P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - Yazılım mühendisliği klasiği sayılabilir. Brooks Yasası bu kitabın ana temasıdır.
+- [Gödel, Escher, Bach: An Eternal Golden Braid - Douglas R. Hofstadter.](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - Sınıflandırması zor bir kitap. Hofstadter Yasası bu kitaptan alıntıdır.
+- [Dilbert Prensibi - Scott Adams](https://www.goodreads.com/book/show/85574.The_Dilbert_Principle) - [Dilbert İlkesini](#the-dilbert-principle) oluşturan yazardan, kurumsal Amerika'ya komik bir bakış.
+- [The Peter Principle - Lawrence J. Peter](https://www.goodreads.com/book/show/890728.The_Peter_Principle) - Another comic look at the challenges of larger organisations and people management, the source of [The Peter Principle](#the-peter-principle).
+
+## Katkıda Bulunmak İçin
+
+Lütfen katkıda bulunun! Bir ekleme veya değişiklik önermek istiyorsanız [bir sorun oluşturun](https://github.com/dwmkerr/hacker-laws/issues/new) veya kendi değişikliklerinizi önermek için [bir PR açın](https://github.com/dwmkerr/hacker-laws/compare) .
+
+Lütfen metin, stil ve benzeri gereksinimler için [Katkıda Bulunma Kılavuzunu](./.github/contributing.md) okuduğunuzdan emin olun. Lütfen projeyle ilgili tartışmalarda [Davranış Kurallarına](./.github/CODE_OF_CONDUCT.md) dikkat edin.
+
+## TODO
+
+Selam!. Buraya ulaştıysanız, henüz yazmadığım bir konunun bağlantısını tıkladınız, bunun için üzgünüm - ve en kısa zamanda tamamlamaya çalışacağım!
+
+Soru ve önerileriniz için [issue](https://github.com/dwmkerr/hacker-laws/issues) açabilirsiniz, ya da katkıda bulunmak isterseniz [Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) açabilirsiniz.
+