13 Apr

Why Rules Rule

Category:UncategorizedTag: , :

I have to admit, I love rules.

They go against my nature to the core, but they are some of the most valuable institutions I put into my life, both personally and professionally.

Rules are all around us.  We follow so many of them each day and don?t even recognize how valuable they are, because when rules are doing their job, you don?t even notice them.

The first rule of your day is likely your alarm clock.  This is a self imposed rule that you have created for yourself to get up at a certain time in the morning.  Try to function in any meaningful way by completely removing that rule and see what happens.

Almost all games we play have rules.  Without rules those games wouldn?t be much fun.

We drive on the correct side of the road in our lane, following rules of traffic, which if not obeyed put us in mortal danger and make the road quite a scary place.

It is a gross understatement to say rules are important to our daily life.

Yet, I am constantly amazed how many people seem to oppose any notion of rules when it comes to our craft of software development.

There is this notion that rules somehow preclude judgment

Somehow the idea has crept into many of our brains that rules and good judgment, (what we might call craftsmanship), are diametrically opposed to each other.

There seems to be a pervasive thought that rules suck all the fun out of things and take away creativity, skill and experience, reducing the follower of such rules to a mindless robot, replaceable by any other robot.

Not only do I think this viewpoint is completely wrong, but I think it is downright destructive to the craft of software development.

Let us first dispel the notion that rules destroy creativity and its kin.

Think about a game like Scrabble.  Scrabble is a game that is based on a very restrictive set of rules.  You basically have only two moves you can do.

  1. Make a word using only letters in your rack and letters on the board.
  2. Discard some letters to get some new ones.

Rules dictate how many letters you can have and what ways you can arrange them.  Yet, how much creativity is actually created by these constraints?

Music is often seen as a cousin to coding, and is another great example of constraints which breed creativity.  Music has a huge amount of constraint.  There are many natural rules about sounds and chords.  We only have a small amount of notes to even work with, yet people have been elaborating on those 12 notes for hundreds of years and new creative sounds are produced every single day!

If you really take the time to think about it, I think you will find that constraints actually breed creativity not destroy it.

The truth is rules come from good judgment at the right time

Let me posit you this question.

When is a better time to make a judgment decision of what to do when a bear attacks you?

  • When the bear is actually attacking you
  • Sitting at your computer with a huge amount of reference material available to you about bear attacks and a calm peaceful environment

If you chose when the bear is actually attacking you turn to page 32.

Page 32:


Having no rules in which to operate, in the heat of the moment, you decide to ?tickle? the bear.  The bear slays you and munches on your bones.  Your adventure has come to an end.

You are DEAD!

The point is that your judgment is much more likely to be sound when you are removed from the situation which you are making the judgment call about.  Unless you are a close relative of Spock, you?ll probably find that human emotions tends to interfere with sound judgment.

This is why I instead firmly believe that we should use our good judgment to formulate rules that we will use in the situations which they apply to rather than to try and execute good judgment when we are engrossed in the situation.

If you still disagree with me here, let?s ponder the example of the alarm clock one more time.  Better yet, I challenge you to make a judgment call each morning of when you should wake up.  You can?t use an alarm clock or any rules.  (Before you do this, you might want to make sure you get your resume polished up.)

alarm clock

How does this all apply to software development?

I?m not going to attempt to address every way in this blog post, perhaps we?ll revisit this subject in the future, because it is so important.  Instead my goal here is to convince you to embrace rules and to not fear setting them for yourself, for your team or for your code.

Some of the biggest failings of teams that I see is the fear of setting rules.  Teams seem to be so afraid of restricting someone or impairing their ability to make judgment calls that they go the direction of never setting any concrete rules, just guidelines or best practices.

There is a huge difference between guidelines and rules.  Guidelines help you make a decision, rules make it for you.  Don?t be fooled into thinking they are the same thing, and don?t fear rules.  I always prefer rules over guidelines, because they are much more valuable.

You can actually measure the effect of a rule, but you can?t easily measure the effect of a guideline.

Let me give you some examples of areas in software development that I think are great places to enforce some rules:

  • Naming conventions
  • Unit testing
  • Process of starting work
  • Who works on work
  • When work is considered done
  • How defects are handled
  • What changes can be made to work in progress
  • What should be in a backlog
  • Language and library choices
  • Data access strategies
  • Dealing with build failures

Every time you are having a conversation which ends up identifying something to improve upon, you should be thinking about how you can codify it into a rule.  Don?t be afraid to step out here.  It?s ok to make the wrong rule and change it later.  If you do this you learn something.

Having rules in place prevents you from making in-the-moment decisions which you later come to regret.

When I go to a buffet, I set rules for how much food I can eat.  When I decide to start a workout routine, I set rules for how often and what duration I will workout.  When I write code, I set rules for how I will write that code.

In any of those areas, when I fail to set rules, I end up failing.  It is human nature.

But rules impede me and end up making me do silly things

Good.  That is called feedback.

Remember back when you were just making judgment calls all the time instead of following rules you or your team preset ahead of time, you weren?t getting any feedback, now you are.  Be happy about it, celebrate!

You can always change the rules.  You can always tweak the parameters, but if you want to have any success in process improvement, it is much like cooking on the stove.  You are much better off with burner dials that have numbers on them or at least some kind of label, then ones with just a blank dial.  If you don?t know where the dial is, how will you know which way to turn it?

Sometimes rules are going to make you do something silly or seemingly extraneous.  Sometimes rules are going to cause you to possibly even do the wrong thing.

But, if you want to have any chance of learning from your mistakes, if you want to truly improve your process, you must resist the urge to break the rules and instead wait for a time to reflect upon the rules and make appropriate changes at that time.

Learn to embrace rules and you?ll suddenly see an improvement in all areas of life where you apply them, especially your software development!

As always, you can subscribe to this RSS feed to follow my posts on elegant code.  Feel free to check out my main personal blog at http://simpleprogrammer.com, which has a wider range of posts, updated 2-3 times a week.  Also, you can follow me on twitter here.

Find me



The opinions and content expressed here are my own and not those of my employer.