In 1906, Italian economist Vilfredo Pareto noted that 80% of the wealth in Italy was held by just 20% of its citizens. In over a century since then, this idea has been put to the test in a number of fields beyond economics, and similar patterns have been found. The exact percentages may vary, but the general observation has emerged over time: the vast majority of effects in many systems are a result of just a small number of the causes.
In programming, this principle can manifest in a number of different ways. One of the more common is in regard to early optimization. Donald Knuth, the noted computer scientist, once said that premature optimization is the root of all evil, and many people take that to mean optimization should be avoided until all other aspects of the code have been finished.
Knuth, however, was referring to a focus solely on performance too early in the process. It's useless to try to tweak every ounce of speed out of a program until you've verified that it even does what it's supposed to. As a more practical matter, the Pareto Principle teaches us that a little bit of work at the outset can have a large impact on performance.
Striking that balance can be difficult, but there are a few easy things that can be done while designing a program, which can handle the bulk of the performance problems with little effort. Some such techniques are listed throughout the remainder of this book, under sidebars labeled Optimization.
Another application of the Pareto Principle involves prioritization of features in a complex application or framework. Rather than trying to build everything all at once, it's often better to start with the minority of features that will provide the most benefit to your users. Doing so allows you to get started on the core focus of the application and get it out to the people who need to use it, while you can refine additional features based on feedback.
Was this article helpful?