Probably only the number of webpages with images of cats is greater than those talking about Pareto principle. Nevertheless I want to add my own just because I think this is not so clear to all my colleagues.

A rough definition of this law may be:

To accomplish the final 20% of a job, you'll need the 80% of the total time.

If you are close to the deadline of a big project, this sentence sounds quite depressing, isn't it?

But if you have some experience, you can say that this principle is absolutely correct. How much time have you spent in moving UI objects one pixel at time until the Project Manager is satisfied? And what about colors? And that damn string that doesn't fit the printed page? And the final comma to be removed from JSON arrays? And that strange bug that only happens on few PCs?

All these things are important - but not fundamental. They don't represent the core of the application, just some details. In fact, another way to express nearly the same concept is:

The Devil hides in the details.

In my opinion, it is all in the difference between a proof of concept and a real application. A software, in order to be given to a customer, must be:

• efficacious - it must do its job
• efficient - the job must be done in the best way possible (according to time constraints and remembering that perfection is impossible to achieve)
• reliable - it must handle failures in a proper way and always preserve user's data
• usable - the user must find it natural to use^[1]

People that doesn't have experience in coding "real" applications usually underestimate the benefits of usability, reliability and sometimes efficiency. Without these characteristics, your software will be nothing more than a proof of concept. And you are not creating proof of concept, aren't you?