The Pareto rule, also known as the 80/20 rule, was named after Italian economist Vilfredo Pareto, who first formulated it in the 20th century. The Pareto principle states that most results come from a small number of causes. Specifically, the Pareto principle states that usually 20% of the causes cause 80% of the results.
The Pareto principle is used in various fields such as economics, business, marketing, software development and more. It is a general concept that can be applied to a variety of tasks and situations, and it aids in problem analysis and resolution by enabling the identification of key causes and objectives.
The article was revised and updated in May 2026.
Task prioritization
Pareto's rule can be used to determine which tasks are most important and should therefore be addressed as a priority. For example, if we look at the bug tracking system, we can find that 20% of the bugs cause 80% of the problems. In that case, we could prioritize solving the most serious errors that will bring the greatest benefit.
Code optimization
Pareto's rule can be used to identify the critical parts of the code that are most frequently used or that took the most time to compute. We could optimize these parts of the code to achieve better application performance.
Testing
The Pareto rule can be used to determine which parts of the application should be tested in priority. For example, if we look at the usage of the application, we can find that 20% of the features are used by 80% of the users. In that case, we could prioritize testing these features to ensure their quality and stability.
Refactoring
Pareto's rule can be used to determine which parts of the code should be refactored as a priority. For example, if we look at historical code change data, we can find that 20% of the code requires 80% of the changes. In that case, we could prioritize refactoring these parts of the code to make them easier to maintain and develop.
How to identify the 20 percent of code that is worth refactoring?
There are several ways you can identify the 20% of code that would be worth refactoring:
- Analysis of code change history: You can examine the history of code changes in the versioning system and see which parts of the code have been changed or fixed the most. These parts might be worth refactoring to make them easier to maintain and develop.
- Using code analysis tools: There are tools that allow you to analyze the code and find out which parts are used the most or which took the most time to calculate. These parts could be worth refactoring to improve application performance.
- Finding critical points in the code: You can examine the code and look for places that are critical to the operation of the application or that are hard to read or hard to maintain. These parts might be worth refactoring to improve quality and maintainability.
It is important to note that code refactoring can be a time and money consuming process, so you should consider the pros and cons of refactoring for your specific situation. It may happen that refactoring the code does not bring the expected result or even harms the code more than it helps.
