Merge pull request #10 from dwmkerr/feat/postels-law

feat: postel's law

1 files changed, 13 insertions, 1 deletions

diff --git a/README.md b/README.md
index 31a4a1e..b467ce8 100644
--- a/README.md
+++ b/README.md
@@ -2,7 +2,6 @@
 
 Laws, Theories, Patterns and Ideas that all developers should know about!
 
-
 <!-- vim-markdown-toc GFM -->
 
 * [Introduction](#introduction)
@@ -10,6 +9,7 @@ Laws, Theories, Patterns and Ideas that all developers should know about!
     * [⭐⭐ 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 Robustness Principle (Postel's Law)](#-the-robustness-principle-postels-law)
     * [⭐⭐⭐ The Unix Philosophy](#-the-unix-philosophy)
     * [⭐The Spotify Model](#the-spotify-model)
 
@@ -21,6 +21,8 @@ There are lots of laws which people discuss when talking about development. This
 
 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
 
 And here we go!
@@ -52,6 +54,16 @@ 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 Robustness Principle (Postel's Law)
+
+[The Robustness Principle on Wikipedia](https://en.wikipedia.org/wiki/Robustness_principle)
+
+> Be conservative in what you do, be liberal in what you accept from others.
+
+Often applied in server application development, this principle states that what you send to others should be as minimal and conformant as possible, but you should be aim to allow non-conformant input if it can be processed.
+
+The goal of this principle is to build systems which are robust, as they can handle poorly formed input if the intent can still be understood. However, there are potentially security implications of accepting malformed input, particularly if the processing of such input is not well tested.
+
 ### ⭐⭐⭐ The Unix Philosophy
 
 [The Unix Philosophy on Wikipedia](https://en.wikipedia.org/wiki/Unix_philosophy)