diff --git a/README.md b/README.md
index c4e9eca..2ff38f4 100644
--- a/README.md
+++ b/README.md
@@ -9,6 +9,7 @@ Laws, Theories, Patterns and Ideas that all developers should know about!
 * [The Laws](#the-laws)
     * [⭐⭐ Conway's Law](#-conways-law)
     * [⭐ Hofstadter's Law](#-hofstadters-law)
+    * [⭐⭐ The Law of Conservation of Complexity (Tessler's Law)](#-the-law-of-conservation-of-complexity-tesslers-law)
     * [⭐⭐⭐ The Unix Philosophy](#-the-unix-philosophy)
     * [⭐The Spotify Model](#the-spotify-model)
 
@@ -41,6 +42,16 @@ 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 (Tessler's Law)
+
+[The Law of Conservation of Complexity on Wikipedia](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity)
+
+This law states that there is a certain amount of complexity in a system which cannot be reduced.
+
+Some complexity in a system is 'inadvertent'. It is a consequence of poor structure, mistakes, or just bad modeling of a problem to solve. Inadvertent complexity can be reduced (or eliminated). However, some complexity is 'intrinsic' - is is a consequence of the complexity inherent in the problem being solved. This complexity can be moved, but not eliminated.
+
+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 Unix Philosophy
 
 [The Unix Philosophy on Wikipedia](https://en.wikipedia.org/wiki/Unix_philosophy)