Pareto principle - 80/20 in Software Development/Support

For many events, roughly 80% of the effect comes from 20% of the cause.

This is the rough translation of the Pareto principle. You may also hear it called the 80-20 rule. With increasing frequency, I’ve seen that this principle is much more important in software development and support than I originally thought. Let’s look at it in some real life examples.

Users Think Your Software Sucks

How many times have you found yourself starting to feel ashamed and downtrodden about your favorite project you’re working on? You start hearing comments on your forums, tweets, and e-mails about how horrible of a job you are doing. Some people find it even necessary to threaten you: “If you continue to suck, I will no longer use your software!” - oh noes. Really?

The last time I ran into this, I was really depressed. I received over 100 emails about how horrible a particular feature I implemented was. I started thinking maybe I did a bad thing. Maybe I shouldn’t have updated that software with this change. However, when I finally tamed my emotions, I noticed that my growth rate of the user base continued to be what it was before the change. Also, I did receive about 10 emails from people saying they liked my change. (In my head, I always multiply the “good” by 8 - because isn’t I thought I had read an interview one time saying that it takes 8 compliments to undo a negative comment. Yep, that’s just me being fluffy but it works for me.) So, I now had 80 good, 100 bad.

What’s more important: the total user base was at 1,000 at the time of the 100th e-mail. This means that only 10% of the user base said something bad. Let’s just round up and say another 10% didn’t like it but wouldn’t say anything. That still leaves 80% of the people liking it. This was a win.

It’s easy to hear the bad and think you need to change your ways. However, when you temper this with the Pareto principle, you’ll start to see that these thoughts are more based on emotion than on actual impact.

Your Software is Buggy

My software isn’t perfect. Maybe it would be if I could thoroughly test each portion of it. However, time doesn’t allow for that. Instead, I get about 80% self-testing - and then I release it. More often than not, bugs are found - just in a delayed fashion and on edge case scenarios. When investigating the bugs, they’re real: they just aren’t that common in the general use of the product.

This is to say, that 80% of the use of your software is probably the 80% that you will self test. The remaining 20% may have bugs - but this is an acceptable risk - especially when pushing out to market. This is a different concept than admitting to having 20% bugs, however. This instead says I have bugs in 20% of my software.

80% of your support calls were solved

This is the biggest issue with people who run a call center. (Trust me, I know. I asked for 95% when I managed. Big mistake!). Instead, when you aim for the 80%, you’re going to make the most impact. This isn’t to say that you would give up on the remaining 20%, but count it as a win with 80. Then, as time permits, go back and continue to work the long tail.

Your examples were measurement of output, not effort

Good catch! For the most part, I’m talking about measurement of output. 80% of this is solved, 20% of that is unsolved, etc. The principle purely says it’s the effort that we should be focusing, the cause, not necessarily the output. I think this is a great measurement or borderline for most things, not just cause and effect.

Final Words

So, start watching the world around you and using the 80-20 rule to provide a frame to it. You’ll start to notice that the application of this will become more apparent in most successful, efficient and accurate ventures. Good luck!