The 80/20 Rule

I’m regularly surprised at how ill handled or abused the 80/20 rule is. In this case, I’m not referring to the Pareto principle, where 80% of an effect comes from 20% of a cause. What I’m referring to is more along the lines of a “rule of thumb.” (I don’t actually know if there’s a technical term for this.) The idea behind the 80/20 rule is simple: almost every rule, policy, or best practice has exceptions. (In short it only applies about 80% of the time.) Naturally, there is nothing special about the 80-20 split. Some things are 90-10, 95-5, or 60-40.

So why bother with a blog entry stating the obvious? Everybody knows that rules have exceptions. However, I have two reasons for mentioning the issue. The first is as an official disclaimer. Nearly every rule, best practice, software pattern, or idea that I (or anyone else) will ever post will have at least one exception. Generally, when I call out a best practice, it should go without saying that there are times when it won’t apply. As developers, it is our responsibility to think critically and to know when not to use an idea. That’s what we’re paid to do. I also believe that we ought to know why any given best practice is considered a good idea. Why do coding standards encourage the use of getters and setters? Why are goto statements considered evil in object oriented code? Why do we make variables private and not public in a class? Answering, “Because everyone else does it that way,” is not good enough. Coding standards should not be about applying a technical form of peer-pressure, they should be about helping developers recognize a potential mistake before it’s made.

The second reason for discussing the 80/20 rule is to point out the consequences of trying to create a blanket policy that doesn’t allow for exceptions. When called out, the notion seems ridiculous but it’s done all the time in our industry. (How many people have had to write three line javadoc comments for a one line getter or setter?) Honestly, some of the worst hacks I’ve ever seen came from attempting to make a design pattern fit a problem that didn’t apply. Well intentioned management policies can violate this rule too. (The concrete examples that I’ve witnessed are worthy of their own blog entries and have been saved for later.) In general though, I would say this:
Life is full of exceptions. Knowing what the exceptions are and how to work around them is at the heart of learning to write good code. Or maybe I should have said, “80% of learning how to write good code is in understanding the 20% of the 80/20 rule.”