feat: Moore's Law

Closes #51.

.gitignore

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

CONTRIBUTORS.md

@@ -0,0 +1 @@
+- [rheh](https://github.com/rheh) - Suggestion - Brooks's Law

README.md

@@ -1,17 +1,32 @@
-# hacker-laws 
-Laws, Theories, Patterns and Ideas that all developers should know about!
+# hacker-laws
+
+Laws, Theories, Principles and Patterns that developers will find useful.
 
 <!-- vim-markdown-toc GFM -->
 
 * [Introduction](#introduction)
-* [The Laws](#the-laws)
-    * [⭐⭐ Conway's Law](#-conways-law)
-    * [⭐ Hofstadter's Law](#-hofstadters-law)
-    * [⭐⭐ The Law of Conservation of Complexity (Tesler's Law)](#-the-law-of-conservation-of-complexity-teslers-law)
-    * [⭐The Law of Triviality](#the-law-of-triviality)
-    * [⭐⭐ The Robustness Principle (Postel's Law)](#-the-robustness-principle-postels-law)
-    * [⭐⭐⭐ The Unix Philosophy](#-the-unix-philosophy)
-    * [⭐The Spotify Model](#the-spotify-model)
+* [Laws](#laws)
+    * [Amdahl's Law](#amdahls-law)
+    * [Brooks's Law](#brookss-law)
+    * [Conway's Law](#conways-law)
+    * [The Hype Cycle & Amara's Law](#the-hype-cycle--amaras-law)
+    * [Hofstadter's Law](#hofstadters-law)
+    * [Moore's Law](#moores-law)
+    * [Parkinson's Law](#parkinsons-law)
+    * [The Law of Conservation of Complexity (Tesler's Law)](#the-law-of-conservation-of-complexity-teslers-law)
+    * [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 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)
+* [TODO](#todo)
 
 <!-- vim-markdown-toc -->
 
@@ -19,16 +34,50 @@ 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:
+
+![Diagram: Amdahl's Law](./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, where as a program which is 95% parallelisable can still achieve significant speed improvements with over a thousand processing units.
+
+As [Moore's Law](#TODO) 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's Law](#brookss-law)
+- [Moore's Law](#TODO)
+
+### Brooks's Law
+
+[Brooks's 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.
+
+See also:
+
+- [Death March](#todo)
+
+### Conway's Law
 
 [Conway's Law on Wikipedia](https://en.wikipedia.org/wiki/Conway%27s_law)
 
@@ -36,7 +85,23 @@ This law suggests that the technical boundaries of a system will reflect the str
 
 See also: 'The Spotify Model'.
 
-### ⭐ Hofstadter's Law
+### 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 fund 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".
+
+### Hofstadter's Law
 
 [Hofstadter's Law on Wikipedia](https://en.wikipedia.org/wiki/Hofstadter%27s_law)
 
@@ -44,7 +109,29 @@ See also: 'The Spotify Model'.
 
 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)
+### 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 semi-conductor technology and quantum computing may mean that Moore's Law could continue to hold true for decades to come.
+
+### 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 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*.
+
+See also:
+
+- [Hofstadter's Law](#hofstadters-law)
+
+### The Law of Conservation of Complexity (Tesler's Law)
 
 [The Law of Conservation of Complexity on Wikipedia](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity)
 
@@ -54,7 +141,7 @@ 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 Triviality
 
 [The Law of Triviality on Wikipedia](https://en.wikipedia.org/wiki/Law_of_triviality)
 
@@ -64,7 +151,46 @@ The common fictional example used is that of a committee approving plans for nuc
 
 The fictional example above led to the usage of the term 'Bike Shedding' as an expression for wasting time on trivial details.
 
-### ⭐⭐ 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 from 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 Robustness Principle (Postel's Law)
 
 [The Robustness Principle on Wikipedia](https://en.wikipedia.org/wiki/Robustness_principle)
 
@@ -74,18 +200,105 @@ 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 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-Orientated 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-Orientated 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-orientated programming, where type hierarchies must be modelled carefully to avoid confusing users of a system.
+
+See also:
+
+- [Object-Orientated 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 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.
+
+See also:
+
+- [Object-Orientated Programming](#todo)
+- [SOLID](#solid)
+- [Duck Typing](#todo)
+- [Decoupling](#todo)
+
+### The Dependency Inversion Principle
+
+[The Dependency Inversion Principle](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-Orientated Programming](#todo)
+- [SOLID](#solid)
+- [Inversion of Control](#todo)
+- [Dependency Injection](#todo)
+
+## TODO
+
+Hi! If you land here, you've clicked on a link to a topic I've not written up yet. 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.