From 32920982ba17972e7849738bbfab6ae2f4c29186 Mon Sep 17 00:00:00 2001 From: Dillon Adams <28228453+DillonAd@users.noreply.github.com> Date: Tue, 14 May 2019 09:38:28 -0500 Subject: [PATCH 01/43] Adding section for Hanlon's Razor --- README.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/README.md b/README.md index 71f3a43..0f35edb 100644 --- a/README.md +++ b/README.md @@ -9,6 +9,7 @@ Laws, Theories, Principles and Patterns that developers will find useful. * [Amdahl's Law](#amdahls-law) * [Brooks's Law](#brookss-law) * [Conway's Law](#conways-law) + * [Hanlon's Razor](#hanlons-razor) * [Hofstadter's Law](#hofstadters-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) @@ -90,6 +91,14 @@ See also: - [The Spotify Model](#the-spotify-model) +### 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." + +This principal 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) From 4b6af52e6061e5e0bb7355b9110ae6c0cf88de03 Mon Sep 17 00:00:00 2001 From: Jeff Nickoloff Date: Tue, 14 May 2019 14:17:31 -0700 Subject: [PATCH 02/43] feat: Dunbar's number feat: Added Dunbar's number --- README.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/README.md b/README.md index 71f3a43..92e62e2 100644 --- a/README.md +++ b/README.md @@ -9,6 +9,7 @@ Laws, Theories, Principles and Patterns that developers will find useful. * [Amdahl's Law](#amdahls-law) * [Brooks's Law](#brookss-law) * [Conway's Law](#conways-law) + * [Dunbar's Number](#dunbars-number) * [Hofstadter's Law](#hofstadters-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) @@ -90,6 +91,18 @@ See also: - [The Spotify Model](#the-spotify-model) +### 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) + ### Hofstadter's Law [Hofstadter's Law on Wikipedia](https://en.wikipedia.org/wiki/Hofstadter%27s_law) From 129a1a6e129a856dc79cd14efb25ec7e27581cd9 Mon Sep 17 00:00:00 2001 From: Hongarc Date: Wed, 15 May 2019 12:47:34 +0700 Subject: [PATCH 03/43] Fix typo --- README.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/README.md b/README.md index 71f3a43..6574a5c 100644 --- a/README.md +++ b/README.md @@ -57,7 +57,7 @@ The diagram below shows some examples of potential improvements in speed: *(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, where as a program which is 95% parallelisable can still achieve significant speed improvements with over a thousand processing units. +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). @@ -72,9 +72,9 @@ See also: > Adding human resources to a late software development project makes it later. -This law suggests that in many cases, attempting to accelerate the delivery of a project which is already late, by adding more people, will make the delivery even later. Brooks is clear that this is an over-simplification, however the general reasoning is that given the ramp up time of new resources and the communication overheads, in the immediate short-term velocity decreases. Also, many tasks may not be divisible, i.e. easily distributed between more resources, meaning the potential velocity increase is also lower. +This law suggests that in many cases, attempting to accelerate the delivery of a project which is already late, by adding more people, will make the delivery even later. Brooks is clear that this is an over-simplification, however, the general reasoning is that given the ramp up time of new resources and the communication overheads, in the immediate short-term velocity decreases. Also, many tasks may not be divisible, i.e. easily distributed between more resources, meaning the potential velocity increase is also lower. -The common phrase in delivery "Nine women can't make a baby in one month" relates to Brooks's Law, in particular the fact that some kinds of work are not divisible or parallelisable. +The common phrase in delivery "Nine women can't make a baby in one month" relates to Brooks's Law, in particular, the fact that some kinds of work are not divisible or parallelisable. See also: @@ -125,7 +125,7 @@ In short, this cycle suggests that there is typically a burst of excitement arou > > (Hyrum Wright) -Hyrum's Law states that when you have a _large enough number of consumers_ of an API, all behaviours of the API (even those not defined as part of a public contract) will eventually come to be depended on by someone. A trivial examples 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. +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: @@ -137,7 +137,7 @@ See also: > 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 semi-conductor technology and quantum computing may mean that Moore's Law could continue to hold true for decades to come. +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. ### Parkinson's Law @@ -147,7 +147,7 @@ Often used to illustrate the sheer speed at which semiconductor and chip technol In it's 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 it's completion and *still take longer than expected*. +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 it's the completion and *still take longer than expected*. See also: @@ -195,7 +195,7 @@ This law states that abstractions, which are generally used in computing to simp 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 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. @@ -221,9 +221,9 @@ The fictional example above led to the usage of the term 'Bike Shedding' as an e [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. +The Unix Philosophy is that software components should be small, and focused on doing one specific thing well. This can make it easier to build systems by composing together small, simple, well-defined units, rather than using large, complex, multi-purpose programs. -Modern practices like 'Microservice Architecture' can be thought of as an application of this law, where services are small, focused and do one specific thing, allowing complex behaviour to be composed from simple building blocks. +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 @@ -286,7 +286,7 @@ These are key principles in [Object-Oriented Programming](#todo). Design princip The first of the '[SOLID](#solid)' principles. This principle suggests that modules or classes should do one thing and one thing only. In more practical terms, this means that a single, small change to a feature of a program should require a change in one component only. For example, changing how a password is validated for complexity should require a change in only one part of the program. -Theoretically this should make code more robust, and easier to change. Knowing that a component which is being changed has a single responsibility only means that _testing_ that change should be easier. Using the earlier example, changing the password complexity component should only be able to affect the features which relate to password complexity. It can be much more difficult to reason about the impact of a change to a component which has many responsibilities. +Theoretically, this should make the code more robust, and easier to change. Knowing that a component 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: @@ -318,9 +318,9 @@ See also: The third of the '[SOLID](#solid)' principles. This principle states that if a component relies on a type, then it should be able to use subtypes of that type, without the system failing or having to know the details of what that subtype is. -As an example, imagine we have a method which reads an XML document from a structure which represents a file. If the method uses a base type 'file', then anything which derives from 'file' should be able to be used in the function. If 'file' supports seeking in reverse, and the xml parser uses that function, but the derived type 'network file' fails when reverse seeking is attempted, then the 'network file' would be violating the principle. +As an example, imagine we have a method which reads an XML document from a structure which represents a file. If the method uses a base type 'file', then anything which derives from 'file' should be 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-orientated programming, where type hierarchies must be modelled carefully to avoid confusing users of a system. +This principle has particular relevance for object-orientated programming, where type hierarchies must be modeled carefully to avoid confusing users of a system. See also: @@ -335,7 +335,7 @@ See also: 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 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. +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-orientated 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. @@ -350,7 +350,7 @@ See also: [The Dependency Inversion Principle](https://en.wikipedia.org/wiki/Dependency_inversion_principle) -> High level modules should not be dependent on low-level implementations. +> 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. From ee9e0e468b50c11488ec6641b7427dd4d08296ac Mon Sep 17 00:00:00 2001 From: Dave Kerr Date: Wed, 15 May 2019 21:20:05 +0800 Subject: [PATCH 04/43] fix: spelling for Parkinson's Law Closes #67 --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 71f3a43..0891d95 100644 --- a/README.md +++ b/README.md @@ -145,9 +145,9 @@ Often used to illustrate the sheer speed at which semiconductor and chip technol > Work expands so as to fill the time available for its completion. -In it's 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. +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 it's completion and *still take longer than expected*. +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: From 4275707dc7edc4cffc013d02dc1f9559491c95fa Mon Sep 17 00:00:00 2001 From: Dave Kerr Date: Wed, 15 May 2019 21:21:52 +0800 Subject: [PATCH 05/43] docs: update Hyrum's Law with XKCD reference Closes #69 --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 0891d95..187f0cc 100644 --- a/README.md +++ b/README.md @@ -130,6 +130,7 @@ Hyrum's Law states that when you have a _large enough number of consumers_ of an See also: - [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions) +- [XKCD 1172](https://xkcd.com/1172/) ### Moore's Law From 525be0e971b50ec0e2db1dd0c26cbdab2fe6f3a1 Mon Sep 17 00:00:00 2001 From: Pepe Bawagan Date: Wed, 15 May 2019 21:48:20 +0800 Subject: [PATCH 06/43] Fix typo --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 187f0cc..da50d53 100644 --- a/README.md +++ b/README.md @@ -170,7 +170,7 @@ However, it should be stressed that Laws such as this are vast generalisations a See also: -- [The Peter Principe](#TODO) +- [The Peter Principle](#TODO) - [Dilbert's Law](#TODO). From 072158be3a98650b775a1b102c794c0c909f8c39 Mon Sep 17 00:00:00 2001 From: Dave Kerr Date: Wed, 15 May 2019 22:27:39 +0800 Subject: [PATCH 07/43] feat: add PR template and contributor guide --- .github/contributing.md | 46 ++++++++++++++++++++++++++++++++ .github/pull_request_template.md | 14 ++++++++++ 2 files changed, 60 insertions(+) create mode 100644 .github/contributing.md create mode 100644 .github/pull_request_template.md diff --git a/.github/contributing.md b/.github/contributing.md new file mode 100644 index 0000000..4412093 --- /dev/null +++ b/.github/contributing.md @@ -0,0 +1,46 @@ +# Contributing Guidelines + +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. +- 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. + +An example law is shown below, which covers most of the key points: + +--- + +### 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. diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md new file mode 100644 index 0000000..aeb9760 --- /dev/null +++ b/.github/pull_request_template.md @@ -0,0 +1,14 @@ +**Pull Request Checklist** + +Please double check the items below! + +- [ ] I have read the [Contributing 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. From 13e88bf308cb821ded4b3b4975ec3b6c516984f4 Mon Sep 17 00:00:00 2001 From: Dave Kerr Date: Wed, 15 May 2019 22:31:10 +0800 Subject: [PATCH 08/43] docs: code of conduct --- .github/CODE_OF_CONDUCT.md | 76 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 76 insertions(+) create mode 100644 .github/CODE_OF_CONDUCT.md diff --git a/.github/CODE_OF_CONDUCT.md b/.github/CODE_OF_CONDUCT.md new file mode 100644 index 0000000..ecbf281 --- /dev/null +++ b/.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 From d593ef07abf190b7b2771870cc97be80a6c70b2b Mon Sep 17 00:00:00 2001 From: Dave Kerr Date: Wed, 15 May 2019 22:43:47 +0800 Subject: [PATCH 09/43] docs: improve contributor guide --- .github/contributing.md | 1 + 1 file changed, 1 insertion(+) diff --git a/.github/contributing.md b/.github/contributing.md index 4412093..6dc01bd 100644 --- a/.github/contributing.md +++ b/.github/contributing.md @@ -11,6 +11,7 @@ The goal of this project is to have a set of _concise_ definitions to laws, prin 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. From 47b5fa2c25e16a5df836f62cc55f6aaf00dc875e Mon Sep 17 00:00:00 2001 From: Dillon Adams <28228453+DillonAd@users.noreply.github.com> Date: Wed, 15 May 2019 09:44:34 -0500 Subject: [PATCH 10/43] Correcting spelling of principle in Hanlon's Razor Section --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 0f35edb..db80601 100644 --- a/README.md +++ b/README.md @@ -97,7 +97,7 @@ See also: > "Never attribute to malice that which is adequately explained by stupidity." -This principal 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. +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 From d3a66b3324d32e7d7c37bb7d4810fc071afb04b3 Mon Sep 17 00:00:00 2001 From: Dillon Adams <28228453+DillonAd@users.noreply.github.com> Date: Wed, 15 May 2019 09:49:44 -0500 Subject: [PATCH 11/43] Adding author's name to Hanlon's Razor section --- README.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index db80601..6110168 100644 --- a/README.md +++ b/README.md @@ -95,7 +95,9 @@ See also: [Hanlon's Razor on Wikipedia](https://en.wikipedia.org/wiki/Hanlon%27s_razor) -> "Never attribute to malice that which is adequately explained by stupidity." +> "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. From e9e3cde668ea1458f7803ec41dbcd7be0311e27f Mon Sep 17 00:00:00 2001 From: Dave Kerr Date: Wed, 15 May 2019 22:56:39 +0800 Subject: [PATCH 12/43] docs: mention twitter for sharing updates --- .github/pull_request_template.md | 1 + 1 file changed, 1 insertion(+) diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index aeb9760..966b6bf 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -12,3 +12,4 @@ 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! From 9e7993284b3e8ce59032950f6c7159e777ab4069 Mon Sep 17 00:00:00 2001 From: Dave Kerr Date: Wed, 15 May 2019 23:25:17 +0800 Subject: [PATCH 13/43] chore: clean up pr guideline text --- .github/pull_request_template.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 966b6bf..da77bc2 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -2,7 +2,7 @@ Please double check the items below! -- [ ] I have read the [Contributing Guidelines](./.github/contributing.md). +- [ ] 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). From 74fad626fee6d9273faa08525a6266a20e17a935 Mon Sep 17 00:00:00 2001 From: Dave Kerr Date: Wed, 15 May 2019 23:35:41 +0800 Subject: [PATCH 14/43] chore: clean up formatting of quotes And add reference for Hofstadter's Law --- README.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 5bfe97f..5983a5d 100644 --- a/README.md +++ b/README.md @@ -95,9 +95,9 @@ See also: [Hanlon's Razor on Wikipedia](https://en.wikipedia.org/wiki/Hanlon%27s_razor) -> "Never attribute to malice that which is adequately explained by stupidity." +> Never attribute to malice that which is adequately explained by stupidity. > -> -Robert J. Hanlon +> 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. @@ -106,6 +106,8 @@ This principle suggests that actions resulting in a negative outcome were not a [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. From 1aab510db419558f571459270479211d60f3229e Mon Sep 17 00:00:00 2001 From: Dave Kerr Date: Thu, 16 May 2019 10:29:21 +0800 Subject: [PATCH 15/43] feat: link for Chinese version --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 5983a5d..cbb4003 100644 --- a/README.md +++ b/README.md @@ -2,6 +2,8 @@ Laws, Theories, Principles and Patterns that developers will find useful. +🇨🇳 [Hacker Laws in Chinese](https://github.com/nusr/hacker-laws-zh) - Thanks [Steve Yu](https://github.com/nusr) + * [Introduction](#introduction) From 6e727e1332ef988c47704c10eaae191d5bd7b79f Mon Sep 17 00:00:00 2001 From: steve xu Date: Thu, 16 May 2019 10:38:51 +0800 Subject: [PATCH 16/43] docs: add chinese link --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 5983a5d..a3d8e66 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,7 @@ # 💻📖 hacker-laws +[中文](https://github.com/nusr/hacker-laws-zh) + Laws, Theories, Principles and Patterns that developers will find useful. From 9c52cd89990cb5960c92ad0d312255fbc07038ef Mon Sep 17 00:00:00 2001 From: Dave Kerr Date: Thu, 16 May 2019 14:00:18 +0800 Subject: [PATCH 17/43] docs: added link to Chinese version --- README.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/README.md b/README.md index 378dd90..13d62dd 100644 --- a/README.md +++ b/README.md @@ -1,10 +1,8 @@ # 💻📖 hacker-laws -[中文](https://github.com/nusr/hacker-laws-zh) - Laws, Theories, Principles and Patterns that developers will find useful. -🇨🇳 [Hacker Laws in Chinese](https://github.com/nusr/hacker-laws-zh) - Thanks [Steve Yu](https://github.com/nusr) +🇨🇳 [中文 / Chinese Version](https://github.com/nusr/hacker-laws-zh) - thanks [Steve Yu](https://github.com/nusr)! From a42732db8525f7cb324dc6257f8d2bbdea8024e6 Mon Sep 17 00:00:00 2001 From: Julio Lozovei Date: Fri, 17 May 2019 14:02:12 -0300 Subject: [PATCH 18/43] add DRY Principle - add DRY definition and example --- README.md | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/README.md b/README.md index 13d62dd..0a57c39 100644 --- a/README.md +++ b/README.md @@ -32,6 +32,7 @@ Laws, Theories, Principles and Patterns that developers will find useful. * [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) * [TODO](#todo) @@ -381,6 +382,36 @@ See also: - [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. + +> The opposite of DRY would be _WET_ (Write Everything Twice or We Enjoy Typing). + +The principle is easy to understand and can be used with any other methodology, design pattern and/or language. It was cited in 1999 by Andrew Hunt and Dave Thomas in the book [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer). + +In practice, if you have the same piece of code/information in two (or more) different places, you can use the DRY Principle to merge those pieces into a single one and reuse it wherever you want/need. The DRY principle can be used for codes, documentations, schemas, build systems... + +Besides avoiding the repetition, DRY help developers to deliver maintainable, readable and reusable code. It also helps developers to keep the testing step easier - in this specific case, DRY keep unit and integration tests simple. Because if the code isn't repeated, you just need to test it a single time. + +In a real-world application, we can translate the use of DRY with this code: + +```js +// check if user is logged in +function isUserLoggedIn() { + const user = context.getUser(); + + return typeof user.id !== null; +} +``` + +In the example above, to check if the user is logged in we can import this function to anywhere and get the result - without DRY, you would write it every time you need to know if the user is logged in. + + ## 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! From cbfe0d4ee46867e9f1e1cdfe4f04c6b98858548a Mon Sep 17 00:00:00 2001 From: Faycel Date: Fri, 17 May 2019 19:21:40 +0100 Subject: [PATCH 19/43] Fixing grammar error Fixing grammar error --- README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 13d62dd..7af01fd 100644 --- a/README.md +++ b/README.md @@ -9,7 +9,7 @@ Laws, Theories, Principles and Patterns that developers will find useful. * [Introduction](#introduction) * [Laws](#laws) * [Amdahl's Law](#amdahls-law) - * [Brooks's Law](#brookss-law) + * [Brooks' Law](#brookss-law) * [Conway's Law](#conways-law) * [Hanlon's Razor](#hanlons-razor) * [Hofstadter's Law](#hofstadters-law) @@ -66,18 +66,18 @@ As [Moore's Law](#moores-law) slows, and the acceleration of individual processo See also: -- [Brooks's Law](#brookss-law) +- [Brooks' Law](#brookss-law) - [Moore's Law](#moores-law) -### Brooks's Law +### Brooks' Law -[Brooks's Law on Wikipedia](https://en.m.wikipedia.org/wiki/Brooks%27s_law) +[Brooks' Law on Wikipedia](https://en.m.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's Law, in particular, the fact that some kinds of work are not divisible or parallelisable. +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. See also: From 6544befce727324ba60f79f2ee3680432e66556c Mon Sep 17 00:00:00 2001 From: Brady Wetherington Date: Fri, 17 May 2019 19:30:08 -0700 Subject: [PATCH 20/43] Replace "Object-Orientated" with "Object-Oriented" --- README.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index 13d62dd..5d008dd 100644 --- a/README.md +++ b/README.md @@ -306,7 +306,7 @@ Theoretically, this should make the code more robust, and easier to change. Know See also: -- [Object-Orientated Programming](#todo) +- [Object-oriented Programming](#todo) - [SOLID](#solid) ### The Open/Closed Principle @@ -323,7 +323,7 @@ This principle has particular relevance for object-oriented programming, where w See also: -- [Object-Orientated Programming](#todo) +- [Object-oriented Programming](#todo) - [SOLID](#solid) ### The Liskov Substitution Principle @@ -336,11 +336,11 @@ The third of the '[SOLID](#solid)' principles. This principle states that if a c 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-orientated programming, where type hierarchies must be modeled carefully to avoid confusing users of a system. +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-Orientated Programming](#todo) +- [Object-oriented Programming](#todo) - [SOLID](#solid) ### The Interface Segregation Principle @@ -353,11 +353,11 @@ The fourth of the '[SOLID](#solid)' principles. This principle states that consu 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-orientated 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. +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-Orientated Programming](#todo) +- [Object-oriented Programming](#todo) - [SOLID](#solid) - [Duck Typing](#todo) - [Decoupling](#todo) @@ -376,7 +376,7 @@ This principle is complex, as it can seem to 'invert' the expected dependencies See also: -- [Object-Orientated Programming](#todo) +- [Object-oriented Programming](#todo) - [SOLID](#solid) - [Inversion of Control](#todo) - [Dependency Injection](#todo) From cfa6b5c39687c10f46cbf83edfb84ca8346aa5ca Mon Sep 17 00:00:00 2001 From: Brady Wetherington Date: Fri, 17 May 2019 19:36:07 -0700 Subject: [PATCH 21/43] Match case on Object-oriented to Object-Oriented --- README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 5d008dd..5e86590 100644 --- a/README.md +++ b/README.md @@ -306,7 +306,7 @@ Theoretically, this should make the code more robust, and easier to change. Know See also: -- [Object-oriented Programming](#todo) +- [Object-Oriented Programming](#todo) - [SOLID](#solid) ### The Open/Closed Principle @@ -323,7 +323,7 @@ This principle has particular relevance for object-oriented programming, where w See also: -- [Object-oriented Programming](#todo) +- [Object-Oriented Programming](#todo) - [SOLID](#solid) ### The Liskov Substitution Principle @@ -340,7 +340,7 @@ This principle has particular relevance for object-oriented programming, where t See also: -- [Object-oriented Programming](#todo) +- [Object-Oriented Programming](#todo) - [SOLID](#solid) ### The Interface Segregation Principle @@ -357,7 +357,7 @@ This principle has particular relevance for object-oriented programming, where i See also: -- [Object-oriented Programming](#todo) +- [Object-Oriented Programming](#todo) - [SOLID](#solid) - [Duck Typing](#todo) - [Decoupling](#todo) @@ -376,7 +376,7 @@ This principle is complex, as it can seem to 'invert' the expected dependencies See also: -- [Object-oriented Programming](#todo) +- [Object-Oriented Programming](#todo) - [SOLID](#solid) - [Inversion of Control](#todo) - [Dependency Injection](#todo) From abfb8de55c6f44c621d90d44bade6c53671c45d4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bal=C3=A1zs=20Richer?= Date: Sat, 18 May 2019 10:42:22 +0200 Subject: [PATCH 22/43] Added Pareto Principle. --- README.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/README.md b/README.md index 13d62dd..c5d9b61 100644 --- a/README.md +++ b/README.md @@ -155,6 +155,25 @@ See also: Often used to illustrate the sheer speed at which semiconductor and chip technology has improved, Moore's prediction has proven to be highly accurate over from the 1970s to the late 2000s. In more recent years, the trend has changed slightly, partly due to [physical limitations on the degree to which components can be miniaturised](https://en.wikipedia.org/wiki/Quantum_tunnelling). However, advancements in parallelisation, and potentially revolutionary changes in semiconductor technology and quantum computing may mean that Moore's Law could continue to hold true for decades to come. +### Pareto principle + +[Pareto principle on Wikipedia](https://en.wikipedia.org/wiki/Pareto_principle) + +>Most things in life are not distributed evenly. + +The Pareto Principle helps you realize that 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 produce 80% of the result +- 20% of the work create 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). + +Real-world example: + +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. + ### Parkinson's Law [Parkinson's Law on Wikipedia](https://en.wikipedia.org/wiki/Parkinson%27s_law) From 0c1c4fa04dce7f301b5c41c1e61ea04eba34d93b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bal=C3=A1zs=20Richer?= Date: Sat, 18 May 2019 10:43:56 +0200 Subject: [PATCH 23/43] Added Pareto Principle to table of contents. --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index c5d9b61..063d144 100644 --- a/README.md +++ b/README.md @@ -16,6 +16,7 @@ Laws, Theories, Principles and Patterns that developers will find useful. * [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) * [Moore's Law](#moores-law) + * [Pareto principle](#pareto-principle) * [Parkinson's Law](#parkinsons-law) * [Putt's Law](#putts-law) * [The Law of Conservation of Complexity (Tesler's Law)](#the-law-of-conservation-of-complexity-teslers-law) From 8e9409fb844037a5d7b4642d9b6a2700ac453937 Mon Sep 17 00:00:00 2001 From: Dave Kerr Date: Sat, 18 May 2019 19:56:52 +0800 Subject: [PATCH 24/43] feat: added reading list - 'the mythical man month' Closes #56. --- README.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 5e86590..9d38c67 100644 --- a/README.md +++ b/README.md @@ -32,6 +32,7 @@ Laws, Theories, Principles and Patterns that developers will find useful. * [The Liskov Substitution Principle](#the-liskov-substitution-principle) * [The Interface Segregation Principle](#the-interface-segregation-principle) * [The Dependency Inversion Principle](#the-dependency-inversion-principle) +* [Reading List](#reading-list) * [TODO](#todo) @@ -79,9 +80,12 @@ This law suggests that in many cases, attempting to accelerate the delivery of a The common phrase in delivery "Nine women can't make a baby in one month" relates to Brooks's 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 @@ -381,8 +385,14 @@ See also: - [Inversion of Control](#todo) - [Dependency Injection](#todo) +## Reading List + +If you have found these concepts interesting, you may enjoy the following books. + +- [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's Law](#brookss-law) is a central theme of the book. + ## 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. +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. From 46bfe090aae12127a5c77d0594d99963043c2597 Mon Sep 17 00:00:00 2001 From: itallmakesense Date: Sat, 18 May 2019 17:52:30 +0300 Subject: [PATCH 25/43] add `Premature Optimization Effect` to the `Laws` --- README.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/README.md b/README.md index 9d38c67..c0d62c2 100644 --- a/README.md +++ b/README.md @@ -17,6 +17,7 @@ Laws, Theories, Principles and Patterns that developers will find useful. * [Hyrum's Law (The Law of Implicit Interfaces)](#hyrums-law-the-law-of-implicit-interfaces) * [Moore's Law](#moores-law) * [Parkinson's Law](#parkinsons-law) + * [Premature Optimization Effect](#premature-optimization-effect) * [Putt's Law](#putts-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) @@ -173,6 +174,18 @@ See also: - [Hofstadter's Law](#hofstadters-law) +### Premature Optimization Effect + +[Source](http://wiki.c2.com/?PrematureOptimization) + +> Premature optimization is the root of all evil. +> +> Donald Knuth + +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) From 0bef1c9a2ce06a0192fe1e03723e3a79503d3a45 Mon Sep 17 00:00:00 2001 From: steve xu Date: Sun, 19 May 2019 20:31:39 +0800 Subject: [PATCH 26/43] feat: add reading list - 'godel,escher,bach:an eternal golden braid' --- README.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 9d38c67..9dcec9a 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ Laws, Theories, Principles and Patterns that developers will find useful. -🇨🇳 [中文 / Chinese Version](https://github.com/nusr/hacker-laws-zh) - thanks [Steve Yu](https://github.com/nusr)! +🇨🇳 [中文 / Chinese Version](https://github.com/nusr/hacker-laws-zh) - thanks [Steve Xu](https://github.com/nusr)! @@ -117,6 +117,12 @@ This principle suggests that actions resulting in a negative outcome were not a You might hear this law referred to when looking at estimates for how long something will take. It seems a truism in software development that we tend to not be very good at accurately estimating how long something will take to deliver. +This is from the book '[Gödel, Escher, Bach: An Eternal Golden Braid](#reading-list)'. + +See also: + +- [Reading List: Gödel, Escher, Bach: An Eternal Golden Braid](#reading-list) + ### The Hype Cycle & Amara's Law [The Hype Cycle on Wikipedia](https://en.wikipedia.org/wiki/Hype_cycle) @@ -390,6 +396,7 @@ See also: If you have found these concepts interesting, you may enjoy the following books. - [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's Law](#brookss-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. ## TODO From d2f4ad77f87479e8fe137319d79c19e87c725c9a Mon Sep 17 00:00:00 2001 From: Julio Lozovei Date: Mon, 20 May 2019 10:15:43 -0300 Subject: [PATCH 27/43] remove code sample + shorten text - remove code sample - reduce text size - add `See also` section --- README.md | 21 ++++----------------- 1 file changed, 4 insertions(+), 17 deletions(-) diff --git a/README.md b/README.md index 0a57c39..7d6d822 100644 --- a/README.md +++ b/README.md @@ -388,28 +388,15 @@ See also: > Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. -DRY is an acronym for _Don't Repeat Yourself_. This principle aims to help developers reducing the repetition of code and keep the information in a single place. +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). -The principle is easy to understand and can be used with any other methodology, design pattern and/or language. It was cited in 1999 by Andrew Hunt and Dave Thomas in the book [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer). +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. -In practice, if you have the same piece of code/information in two (or more) different places, you can use the DRY Principle to merge those pieces into a single one and reuse it wherever you want/need. The DRY principle can be used for codes, documentations, schemas, build systems... +See also: -Besides avoiding the repetition, DRY help developers to deliver maintainable, readable and reusable code. It also helps developers to keep the testing step easier - in this specific case, DRY keep unit and integration tests simple. Because if the code isn't repeated, you just need to test it a single time. - -In a real-world application, we can translate the use of DRY with this code: - -```js -// check if user is logged in -function isUserLoggedIn() { - const user = context.getUser(); - - return typeof user.id !== null; -} -``` - -In the example above, to check if the user is logged in we can import this function to anywhere and get the result - without DRY, you would write it every time you need to know if the user is logged in. +- [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) ## TODO From d8bd0d36753b2efdd3d07ea9f8633b47e7ae19be Mon Sep 17 00:00:00 2001 From: Dave Kerr Date: Wed, 22 May 2019 23:35:50 +0800 Subject: [PATCH 28/43] docs: minor edits of pareto princple --- README.md | 45 ++++++++++++++++++++++++--------------------- 1 file changed, 24 insertions(+), 21 deletions(-) diff --git a/README.md b/README.md index 72faa18..61daf03 100644 --- a/README.md +++ b/README.md @@ -9,14 +9,13 @@ Laws, Theories, Principles and Patterns that developers will find useful. * [Introduction](#introduction) * [Laws](#laws) * [Amdahl's Law](#amdahls-law) - * [Brooks' Law](#brookss-law) + * [Brooks' Law](#brooks-law) * [Conway's Law](#conways-law) * [Hanlon's Razor](#hanlons-razor) * [Hofstadter's Law](#hofstadters-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) * [Moore's Law](#moores-law) - * [Pareto principle](#pareto-principle) * [Parkinson's Law](#parkinsons-law) * [Putt's Law](#putts-law) * [The Law of Conservation of Complexity (Tesler's Law)](#the-law-of-conservation-of-complexity-teslers-law) @@ -26,6 +25,7 @@ Laws, Theories, Principles and Patterns that developers will find useful. * [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) @@ -167,25 +167,6 @@ See also: Often used to illustrate the sheer speed at which semiconductor and chip technology has improved, Moore's prediction has proven to be highly accurate over from the 1970s to the late 2000s. In more recent years, the trend has changed slightly, partly due to [physical limitations on the degree to which components can be miniaturised](https://en.wikipedia.org/wiki/Quantum_tunnelling). However, advancements in parallelisation, and potentially revolutionary changes in semiconductor technology and quantum computing may mean that Moore's Law could continue to hold true for decades to come. -### Pareto principle - -[Pareto principle on Wikipedia](https://en.wikipedia.org/wiki/Pareto_principle) - ->Most things in life are not distributed evenly. - -The Pareto Principle helps you realize that 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 produce 80% of the result -- 20% of the work create 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). - -Real-world example: - -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. - ### Parkinson's Law [Parkinson's Law on Wikipedia](https://en.wikipedia.org/wiki/Parkinson%27s_law) @@ -303,6 +284,28 @@ See also: 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) From 87c958ce810bd2ed4239c831bad29214e4ffd567 Mon Sep 17 00:00:00 2001 From: Nuno Barreiro Date: Mon, 27 May 2019 15:26:17 +0100 Subject: [PATCH 29/43] added YAGNI to list of principles --- README.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/README.md b/README.md index 61daf03..d02b83b 100644 --- a/README.md +++ b/README.md @@ -34,6 +34,7 @@ Laws, Theories, Principles and Patterns that developers will find useful. * [The Interface Segregation Principle](#the-interface-segregation-principle) * [The Dependency Inversion Principle](#the-dependency-inversion-principle) * [The DRY Principle](#the-dry-principle) + * [YAGNI](#yagni) * [Reading List](#reading-list) * [TODO](#todo) @@ -431,6 +432,16 @@ See also: - [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) +### YAGNI + +This is an acronym for _**Y**ou **A**ren't **G**onna **N**eed **I**t_ + +This Extreme Programming (XP) principle tells developers that they should only implement functionality that is required for the immediate present and avoid attempts to predict the future by implementing functionality that won't be used immediately, rather implement it only when deemed necessary. + +Some of the issues a developer can be faced with in a project that does not respect this principle are: +* Unnecessary increase of the overall codebase size with unused code; +* Time and productivity wasted on functionality that brings no value + ## Reading List If you have found these concepts interesting, you may enjoy the following books. From 87932e6d01bdbe73893fec0e23d152ad97765580 Mon Sep 17 00:00:00 2001 From: Nuno Barreiro Date: Mon, 27 May 2019 15:36:03 +0100 Subject: [PATCH 30/43] YAGNI principle - include quote and wiki article --- README.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/README.md b/README.md index d02b83b..518d627 100644 --- a/README.md +++ b/README.md @@ -436,12 +436,16 @@ See also: 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 tells developers that they should only implement functionality that is required for the immediate present and avoid attempts to predict the future by implementing functionality that won't be used immediately, rather implement it only when deemed necessary. Some of the issues a developer can be faced with in a project that does not respect this principle are: * Unnecessary increase of the overall codebase size with unused code; * Time and productivity wasted on functionality that brings no value +_[Check YAGNI article on Wikipedia](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it)_ + ## Reading List If you have found these concepts interesting, you may enjoy the following books. From da8ec03813319a1cabd399737fb45323efaae182 Mon Sep 17 00:00:00 2001 From: Dave Kerr Date: Sat, 1 Jun 2019 17:22:05 +0800 Subject: [PATCH 31/43] docs: add link to korean version Fixes #114. --- README.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/README.md b/README.md index 6481721..23bd59a 100644 --- a/README.md +++ b/README.md @@ -3,6 +3,9 @@ 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)! +🇰🇷 [한국어 / Korean Version](https://github.com/codeanddonuts/hacker-laws-kr) - thanks [Doughnut](https://github.com/codeanddonuts)! + +--- From 1af5af643cfa3cc1a64950fadcac5fe2a62e39ae Mon Sep 17 00:00:00 2001 From: Dave Kerr Date: Sat, 1 Jun 2019 17:23:32 +0800 Subject: [PATCH 32/43] chore: fix indents --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 23bd59a..c79926b 100644 --- a/README.md +++ b/README.md @@ -2,8 +2,8 @@ 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)! -🇰🇷 [한국어 / Korean Version](https://github.com/codeanddonuts/hacker-laws-kr) - thanks [Doughnut](https://github.com/codeanddonuts)! +- 🇨🇳 [中文 / Chinese Version](https://github.com/nusr/hacker-laws-zh) - thanks [Steve Xu](https://github.com/nusr)! +- 🇰🇷 [한국어 / Korean Version](https://github.com/codeanddonuts/hacker-laws-kr) - thanks [Doughnut](https://github.com/codeanddonuts)! --- From 6988abff1e3f17763cc99bfc6bf5293c5b05c670 Mon Sep 17 00:00:00 2001 From: Matthias Zeis Date: Sun, 2 Jun 2019 14:59:48 +0200 Subject: [PATCH 33/43] Fix link to Brook's Law --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index c79926b..adea7d8 100644 --- a/README.md +++ b/README.md @@ -451,7 +451,7 @@ See also: If you have found these concepts interesting, you may enjoy the following books. -- [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's Law](#brookss-law) is a central theme of the book. +- [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's 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. ## TODO From 85076029352621a2a1cd0e3ecb938eb0c32280c2 Mon Sep 17 00:00:00 2001 From: Matthias Zeis Date: Sun, 2 Jun 2019 15:04:21 +0200 Subject: [PATCH 34/43] Fix more links to Brooks' Law --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index adea7d8..eec17e6 100644 --- a/README.md +++ b/README.md @@ -73,7 +73,7 @@ As [Moore's Law](#moores-law) slows, and the acceleration of individual processo See also: -- [Brooks' Law](#brookss-law) +- [Brooks' Law](#brooks-law) - [Moore's Law](#moores-law) ### Brooks' Law @@ -451,7 +451,7 @@ See also: If you have found these concepts interesting, you may enjoy the following books. -- [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's Law](#brooks-law) is a central theme of the book. +- [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. ## TODO From e4aa6ec6dddf03cd241713c9347f84bc1f59de86 Mon Sep 17 00:00:00 2001 From: Alena Batitskaya Date: Wed, 5 Jun 2019 04:54:13 +0300 Subject: [PATCH 35/43] The link to Russian version added --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index eec17e6..9f105ec 100644 --- a/README.md +++ b/README.md @@ -4,6 +4,7 @@ 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)! - 🇰🇷 [한국어 / 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)! --- From 5d5f3a5748a3600dfc8ff2c3f7f821adf736b9c5 Mon Sep 17 00:00:00 2001 From: Dave Kerr Date: Thu, 6 Jun 2019 20:51:36 -0400 Subject: [PATCH 36/43] chore: indentation --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 9f105ec..c97adf4 100644 --- a/README.md +++ b/README.md @@ -4,7 +4,7 @@ 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)! - 🇰🇷 [한국어 / 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)! +- 🇷🇺 [Русская версия / Russian Version](https://github.com/solarrust/hacker-laws) - thanks [Alena Batitskaya](https://github.com/solarrust)! --- From 065188a4e10f674c2bfbb6b1504b8970a570970c Mon Sep 17 00:00:00 2001 From: Pavel Date: Fri, 7 Jun 2019 17:00:10 +0300 Subject: [PATCH 37/43] Fixed link name due consistency support. --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index c97adf4..ed9c4ec 100644 --- a/README.md +++ b/README.md @@ -415,7 +415,7 @@ See also: ### The Dependency Inversion Principle -[The Dependency Inversion Principle](https://en.wikipedia.org/wiki/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. From 4f11a2b05179fed09f1d3669ac106077ea195675 Mon Sep 17 00:00:00 2001 From: Dave Kerr Date: Tue, 11 Jun 2019 16:17:45 +0800 Subject: [PATCH 38/43] docs: link to turkish version Closes #122. --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index ed9c4ec..eee3ba2 100644 --- a/README.md +++ b/README.md @@ -5,6 +5,7 @@ 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)! - 🇰🇷 [한국어 / 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) --- From 6a7b48161af6e1062a028aa03fa572c00b6f042d Mon Sep 17 00:00:00 2001 From: Dave Kerr Date: Tue, 11 Jun 2019 21:23:37 +0800 Subject: [PATCH 39/43] docs: yagni formatting --- README.md | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index 88fbf6c..af4d048 100644 --- a/README.md +++ b/README.md @@ -451,22 +451,28 @@ See also: ### 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")_ +> 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 tells developers that they should only implement functionality that is required for the immediate present and avoid attempts to predict the future by implementing functionality that won't be used immediately, rather implement it only when deemed necessary. +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. -Some of the issues a developer can be faced with in a project that does not respect this principle are: -* Unnecessary increase of the overall codebase size with unused code; -* Time and productivity wasted on functionality that brings no value +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) -_[Check YAGNI article on Wikipedia](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it)_ ## 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. From e971cdee3f67e259c048ffb76c3a5be5451b8726 Mon Sep 17 00:00:00 2001 From: Dave Kerr Date: Tue, 11 Jun 2019 21:54:38 +0800 Subject: [PATCH 40/43] chore: added full-stop --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index af4d048..29b740a 100644 --- a/README.md +++ b/README.md @@ -453,7 +453,7 @@ See also: [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_ +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. > From 03c972192444ad4b7a3b4bf9ffaac891806a9608 Mon Sep 17 00:00:00 2001 From: Dave Kerr Date: Mon, 17 Jun 2019 15:04:30 +0800 Subject: [PATCH 41/43] chore: minor tweaks to wording --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index a71eb05..955acdc 100644 --- a/README.md +++ b/README.md @@ -203,11 +203,11 @@ See also: ### Premature Optimization Effect -[Source](http://wiki.c2.com/?PrematureOptimization) +[Premature Optimization on WikiWikiWeb](http://wiki.c2.com/?PrematureOptimization) > Premature optimization is the root of all evil. > -> Donald Knuth +> [(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%." From b01e90206267ab8af7c6110bccc59ca7e1d4d310 Mon Sep 17 00:00:00 2001 From: Dave Kerr Date: Mon, 17 Jun 2019 15:30:06 +0800 Subject: [PATCH 42/43] chore: add link to joel's profile --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 955acdc..6139033 100644 --- a/README.md +++ b/README.md @@ -249,7 +249,7 @@ One interesting element to this law is the suggestion that even by simplifying t > All non-trivial abstractions, to some degree, are leaky. > -> (Joel Spolsky) +> [(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. From 83f0cd26bd356ac0cedb8cb4ec2c29faf250cd06 Mon Sep 17 00:00:00 2001 From: Dave Kerr Date: Mon, 17 Jun 2019 15:37:58 +0800 Subject: [PATCH 43/43] chore: cleanup twitter handle --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 6139033..c34854a 100644 --- a/README.md +++ b/README.md @@ -249,7 +249,7 @@ One interesting element to this law is the suggestion that even by simplifying t > All non-trivial abstractions, to some degree, are leaky. > -> [(Joel Spolsky)](https://twitter.com/spolsky) +> ([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.