The Pareto principle (a.k.a. the 80-20 rule, the law of the vital few and the principle of factor sparsity) states that, for many events, 80% of the effects comes from 20% of the causes. (e.g. Your wife might claim that you wear 20% of your closet clothes about 80% of the time… ;-)
I will argue that pareto principle conceals one of the most important princples in software (and not only in software) management – Don’t try to do more. Just do more of the right things!
* Don’t invest too your time in dark software corners since the same principle will catch you with investing 80% of your force with only 20% value (e.g. What will happen if someone disconnect the database network cable 1 minute before DST transition… etc.)
* Don’t over design since you will bump into the 80% investment for only 20% value again – Don’t drill the holes for air-condition system before you have one, since you might find yourself a bunch of holes in the wall…
* While planning, always ask yourself if you can do more for less and try to find that thin-gray-line that cross the 21% effort for the 81% value* – try to identify how to invest minimal effort (~20%) to create enough (~80%) business value.
* In performance tuning you want to find the silver bullet that with minimal effort (let’s say 20%) solve 80% of your issues (a.k.a. low hanging fruits)
* Workforce wise – Jack Welch‘s vitality model has been described as a “20-70-10” system. The “top 20” percent of the workforce is most productive, and 70% (the “vital 70”) work adequately. The other 10% (“bottom 10”) are non-producers and should be fired. Rank-and-yank ideologues credit Welch’s rank-and-yank system with a 28-fold increase in earnings (and a 5-fold increase in revenue) at GE between 1981 and 2001 – Obviously, this is a tremendously competitive model of organization and all criticisms of both the morality and (in)effectiveness of such a Dog Eat Dog method of social cohesion apply but as a manager you must take this in mind since reality and statistics (law of large numbers) do show that the “top 20” percent of the workforce is most productive and is doing 80% of the work…
I would even dare claiming that, perfectionism is a strong indication for weak leadership!
* Note: I was told that everyone knows this principle but the question is how to do it… so my tip (and I promise to post more around this dilemma) is to handle this with-in the scoping of the feature or module; efficient scoping should get very fast to ROI (look for the items with low ROI) and risk analysis (look for the items in high risk and try to understand where the risk come from) and soon after the tradeoff discussion which is the perfect time to take the hard “cutting” decisions and for doing this you must have someone in the room with deep customer understanding; e.g. In most systems it is very “easy” to cut enterprise-readiness features to simplify development (I18N, Security, Upgrade, Scalability, High Availability, Distribution, Monitoring etc.) and many of those features can be added later if needed with no real overhead (warning: you must know what you are doing to make it work so don’t try this at home if you don’t have professionals with you);