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.
- Make a word using only letters in your rack and letters on the board.
- 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.)
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!
You didn’t go here, but I’ll say it anyway because I think it’s quite applicable. In regards to religion and morality, people make rules for themselves all the time (or impose rules on themselves suggested by their church or some spiritual evangelist that they revere). Rules in this domain grow integrity, provide moral safety, and engender dependability.
As for how it applies to software development, you’ve hit the nail right on the head. I would also mention how Convention over Configuration is in favor of setting up rules for your codebase (alluded to by your “Naming Conventions” bullet point). If you set rules about how classes/objects will be named, you can teach your codebase how to reliably find them, construct them, wire them up as dependencies via an IoC/DI container, etc.
Great stuff, thanks for sharing.
Things are not black and white. No, rules cannot be used in any situation. Rules can be contradicting even if they are great rules. To take the simplest and broadest set of rules – the ten commandments – sometimes you reach a situation where you cannot uphold all ten. In something as complex as coding it is bound to be difficult to set up a ruleset that will not contradict in some way.
Rules are all about taxanomy – as a beginner you adher strictly to the rules to learn them by heart. When you reached a competent level – you don’t need the rules because you know them by heart and you are a living extension of the rules as you start to learn how the rules came to be. When you master the area of expertice, you know when to break and create the (new) rules.
There are no silverbullets. There is experience. You cannot learn from other’s experience, but you can question your own experience from the experience of your peers. No matter how brilliant the advice, you can only judge it’s validity if you have experience in the field.
And black-and-white-rules ™ like “We only use the ICriteria API in NHibernate when querying” will certainly help making sure that everyone knows how to read the codebase in respect to querying, but it will have people jumping through hoops just to uphold this rule. Another good example is “We must have 80% test coverage”. Why? Are we certain that 80% coverage is the magic number that will magically turn our code into infallible code?
So, to sum up – I agree that rules are important while learning (and who isn’t learning something new everyday), but rules come at a cost. Everytime you decide to do things in a certain way, it is a matter of weighing positives and negatives. Yes, following a methodology such as SCRUM, TDD (pick your poison) will help you in some ways, but it will just as certainly hinder you in others. As for you analogy about alarm clocks – I never use one :-). And in traffic we break the rules often, because if we follow them without question, we will have an accident when the old lady trips in the crossing (In Denmark the cardinal ‘rule’ in traffic law is that “You should be considerate” – subordinate is “You should drive in the right side of the road” – in other words, consideration takes precedence over the more rigid laws). In my daughter’s kindergarten, I would much rather have a sign saying to the cleaning personel: “Clean as if you lived here” than a checklist. Follow the rules in spirit not in the letter is my take.
PS! Sorry, that got a lot more long-winded than it was originally intended…
Interesting perspective, but I have to completely disagree.
As humans, we tend to
It is interesting as a third-party to read both of your responses. It appears you guys are saying more in common than you believe you are.
In every case that Magnus gives an example of breaking a rule, he actually is talking about modifying the specific rule or falling back on a more general, more important rule (in one case he called it “[following] the rules in spirit,” which is true for the more specific, less important rules that might have been so specific to only have utility in one specific situation). The problem I see is that Magnus is unwilling to admit that there are underlying, general rules/principles that always have applicability, even though many of his examples point to that (kindergarten cleaning, courteous driving, etc.).
There is one more point that Magnus makes made that bothered me, and I don’t necessarily want to make this a debate about religion. He made a statement that there are situations where a person is literally unable to keep all Ten Commandments. This is just a foolish argument that is not only wrong but inconsistent with the rest of the examples Magnus gave. Can you really give an example where all ten can’t be kept? There’s only 10 and they aren’t contradictory, so I’m having a hard time seeing your point of view with out any example. Perhaps your conclusion on this particular subject is because of disenfranchisement from a particular event or a certain religion, but again, it is inconsistent with the rest of your examples. If you come to the realization that all of your examples pointed to there being underlying general principles/rules with applicability to all things, you should come to the same conclusion about the Ten Commandments.
Okay – I’ll try to answer the both of you at the same time.
About the ten commandments – I probably wasn’t clear – what I meant was that even the ten commandments are hard to keep (Military duty and “Thou shall not kill”). I made it sound like they were contradictory which they are not (unless you have some very special circumstances :-)).
What we disagree on (as I understand it), is that I always favour principles and guidelines over rules when it comes to programming. The problem with a rule is that it is a 100% (Everytime we make a view, we _must_ have a viewmodel) – instead of saying: “When making a view consider making a viewmodel”).
When you can do stuff that is clearly against better judgement and justify it by going: “But the rules state…” I believe we are in great trouble. My beef with making rules about software design is that software design is all about trade-offs. When we do things a certain way, we favour something over another. And if we lock ourselves out of making that exception to a rule (that applies well 95% of the time), we are making sub-optimal software. And if we alter the rule – we will end up hurting the 95% of the code where it is applied well.
I’m not saying that principles, best practice should be avoided – quite the contrary, just don’t make them universal truths.
Ah, sorry it took so long, but I actually agree with you in many ways.
I agree we can not make rules about software development in general.
The main point I am trying to get across in this post is that we need to make rules for ourselves and for our teams, that are specific to that situation.
I usually make rules and guidelines. But they are not generalization, but specific to a team or set of circumstances and they may change.
Rules need to be something that can be measured and is going to be something we are going to universally try to apply for some reason.
Guidelines are things I use to get the spirit of what is trying to be accomplished across, when a rule is going to be too specific.
All okay… special circumstances and all that ;-).
I probably need an example or two of such a rule to fully understand where you are going with these rules and why you need to measure them 🙂
I embrace best practices but abhor the simplicity of rule based decision making in practice. If a then b works well with mathematics but less so with emotional beings. We’re maniacally moody, obstinately creative and notoriously fickle.
Your post got me to review a topic I used in estimation but had forgotten:
“an admissible decision rule is a rule for making a decision such that there isn’t any other rule that is always “better” than it, in a specific sense defined below.”