The Pareto Principle in Sofware Engineering and Why it Matters
The Pareto principle, seems somewhat magical at times - 20% of the floor of a room accepts 80% of footsteps. It is of course of no magical origin - the normal distribution - the area under the highest 20% (of the X axis), accounts for roughly 80% of the area under the curve.
So what does it mean for software engineering?
It means a lot of things - mostly the correlation between causes and results - here are a few so you can get a sense:
- 80% of bugs and security flaws are in 20% of the codebase
- 80% of test failures are due to 20% of the test cases
- 80% of users employ only 20% of a system's features
- 80% of performace gains can be achieved by optimizing 20% of the codebase
So what's the takeaway?
Focus on the results you want and then focus your efforts on the 'vital few' root causes. Of course you should not totally dusregard everything else while you are at it - e.g if you have constant issues with a system, find the hotspots of code that are usually changed before issues arise - they are part if the 20% of the code you should refactor.
Also the Pareto rule holds true even for systems that are nit troublesome. Their fewer issues also are hidibg in 20% of the causes.
Always know what you optimize against and how you measure it and remember - every optimization is an endless process on itself, so know when to stop.