Principles – Quick notes

Robustness principle – Postel’s law, after Jon Postel

Programs that send messages to other machines (or to other programs on the same machine) should conform completely to the specifications, but programs that receive messages should accept non-conformant input as long as the meaning is clear.

Rule of least power

In programming, the rule of least power is a design principle that “suggests choosing the least powerful [computer] language suitable for a given purpose”.

Principle of least astonishment

The principle of least astonishment (POLA), also called the principle of least surprise (alternatively a “law” or “rule”)
applies to user interface and software design.
“If a necessary feature has a high astonishment factor, it may be necessary to redesign the feature.”

When two elements of an interface conflict, or are ambiguous, the behavior should be that which will least surprise the user; in particular a programmer should try to think of the behavior that will least surprise someone who uses the program.

Pareto principle

The Pareto principle (also known as the 80/20 rule, the law of the vital few, or the principle of factor sparsity).
It states that, for many events, roughly 80% of the effects come from 20% of the causes.

It was also discovered that in general the 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.

Keep it simple, stupid (keep it simple and straightforward)

The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided. 

Don’t repeat yourself 

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

Don’t repeat yourself (DRY, or sometimes do not repeat yourself) is a principle of software development aimed at reducing repetition of software patterns, replacing it with abstractions or using data normalization to avoid redundancy.


The DRY principle stands for “Don’t Repeat Yourself” and requires that any piece of domain knowledge has a single representation in your code base. In other words, in requires that you don’t duplicate the domain knowledge.

The DAMP principle stands for “Descriptive and Meaningful Phrases” and promotes the readability of the code.