Pareto Principle in Technology

I first heard of the Pareto Principle when I was at university studying economics. It was used in reference to wealth distribution (which was what Pareto was studying) where it had been observed that 20% of the people controlled 80% of the wealth. Over time more studies showed the same sort of distribution.

With respect to technology it is a handy rule of thumb that while not exact gives you something to go from when thinking about issues. A good recent example are analytical reports such as from AdMob of the applications on the Apple online software store (where Apple boasts of the tens of thousands of applications) wherein it was found that a small number of the applications account for most of the traffic and most of the profit. Various limitations (such as a set top 10 list) feed into some of this behavior but largely it boils down to most of the applications having very little value, leading to few people recommending or using them.

In software development the Pareto Principle also rears its head. In iterative approaches like Agile you work on a feature list from a priority list, with the highest value items first, in small batches. Rather than trying to deliver all 100 pieces of functionality that you would like to see you deliver them in batches of five or so and because the first ones being delivered have the highest value you might get 20% of them done (20 features) and have most of the benefits that you want, rather than taking a lot more time and maybe missing the mark with a lot of the work. Delivering sooner rather than later, even if it is a small amount of functionality, also plays into this approach.

Studies by large companies like Microsoft find results like fixing the top 20% of the bugs (by frequency of complaint) results in 80% percent of the errors and crashes going away.

Many examples can be found all around us of the Pareto Principle at work. As far as technology goes it is a good idea to keep it in the front of your mind when you are deciding how you should approach your projects. What is the smallest amount of features / product that you can deliver that provide the biggest bang? Grab this low hanging fruit and get something out rather than trying to design the ultimate application that does everything. You may find that after a few iterations that what you have is good enough and you can then move onto another project and find more success rather than continuing to try and reach a shifting and unattainable goal.