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