The PoLA is one of my favorite principles and I wish it's known as much as the KISS principle, maybe even more. It's also a playful way to think about anything you want to create and is supposed to be used by others.
Meet the PoLA
The idea behind it is straightforward - anything you create must not astonish or negatively surprise. As little WTFs as possible, which can help you to avoid bugs introduced by humans and provide a good user experience. This basically means to follow consistency, common user expectations and user's experience. The principle is universally applicable similarly as KISS and as a software developer I use it often to define interfaces, code behavior or in software architecture discussions
An example
Let me demonstrate that on the famous Javascript comparison operator ==. The comparison behaves this way for values "", [] and 0:
>> [] == 0
true
>> "" == 0
true
>> "" == []
true
For these values it behaves like a transitive relation. However when you replace "" with "0", "0" == [] returns actually false:
>> [] == 0
true
>> "0" == 0
true
>> "0" == []
false
If you know all the necessary Javascript details this behavior might make sense to you, but for the rest of the humanity it, well... it totally doesn't. And that's the point. How does it break the principle of least astonishment specifically?
You might say that the last statement should be true so it follows the behavior of the rest of the comparisons, but I think to really follow the principle of least astonishment the rest of the comparisons shouldn't return true in the first place. They should either throw an exception (comparing something which isn't really comparable), return undefined (result of such comparisons shouldn't be really defined) or just return false (they are not really equal). This actually shows nicely PoLA since the right solution sometimes really depends on the context.
To be fair Javascript also has strict operator === which has less astonishing behavior, but hey, that wouldn't really demonstrate PoLA, would it? And == is the first thing which anyone coming from a different programming language would use.
So...
The PoLA is a simple but really powerful principle. When designing with PoLA in mind it helps to explicitly consider more perspectives which leads to less bugs and problems.
Do you have any examples of PoLA violations? They are usually great lessons learned.
Top comments (3)
Yay! Thanks for the excellent advice! I used to apply PoLA a lot in my day job (now retired!), and had a nuance to relate, something that you allude to with the JS example - astonishment depends on the audience - it's not a facet of the behaviour itself but the observer's expectations. As such it's useful to identify the group(s) of people you are trying not to astonish, and what would surprise them, through user/UX testing, and working through stories / scenarios when forming behavioural (large scale) requirements. Frequently, a development team's idea of 'common sense' doesn't match the customers (cf: Javascript's designers vs. confused users!)
Clashes of expectations I have noticed:
I've never actually thought about Word and Chrome this way, but thanks to you I realized that these are really great examples. In context of any operating systems and their look and feel they don't really fit into any system known to humanity.
About JavaScript, to be honest... I have never fully remembered JavaScript's true / false or truphy / falsy rules well. I have my favourite "cheat sheets" where I can have a look, but still it's real hell! Typescript brought a bit more strict checking.
What I really love is Typescript's "optional chaining" instead of JavaScript talkative conditionals. And I guess I'm not the only one because JavaScript new version is going to use it too 😊 (for example: javascript.info/optional-chaining)