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.”

Why Write About Beginning Java

After some careful consideration, I’ve decided to include “Beginning Java” entries in my blog. When I was in college, I noticed that academia seems to feel that it’s not worth writing anything that isn’t cutting edge. Working out in the “real world” afterward, I found plenty of people who act as though the glory in programming (if you can call it that) comes from knowing the rare and obscure hacks, compiler issues, and language features that separate the true alpha geeks from the wannabes.

Frankly, having written code since the second grade, gotten two degrees on the subject, and done it professionally for the last decade, I tend to be of the opinion that coding is what I do, not who I am. I also observed something else while getting my brown belt in Kempo: the thing that really separates the white belts from the black belts isn’t who can do the complicated stuff like tornado kicks, it’s how efficiently and consistently they can do the basics like blocking and punching.

So what makes it the basics interesting? For me it’s questioning why the things we call best practices actually are (or are not in some cases). It’s well and fine to document what a dynamic proxy is and why anyone would need one (and maybe I will someday) but I think it’s also important to periodically revisit the industry standards that everyone follows and ask, “are we doing what’s best or are we acting like lemmings?”

I love the fact that someone was willing to take a stand and declare that getters and setters are evil. Even if I didn’t agree (which is not the case as it turns out), it encourages programmers to stop and think critically. I don’t know if the things that I plan to write will turn out to be as profound or widely noticed, but in the spirit of, “when a developer stops thinking, he’s overpaid,” I intend to a post a few of my own back-to-basics blog entries.