Rule #1 - Be Consistent

When I was in graduate school for particle physics, I moved to France to work at CERN, the European Center for Particle Physics. Most physicists worked at the CERN main site which has dozens of office buildings, warehouses and experimental halls. Trying to accommodate the thousands of workers and scientists could sometimes be difficult. I worked on the OPAL experiment which populated a few office buildings far from the main entrance, but still part of the main site.

In order to accommodate the growing number of scientists working at the site, temporary office trailers had been put up around the parking lot. Additionally, a line of trailers was put right in the middle of the parking lot splitting it in two allowing just enough room for cars to go around at one end. I was assigned the office on the point of this line of trailers in the middle of the parking lot.

From my office I could see all the surrounding office buildings and trailers. And they could also see me.

I worked closely with people from several of the different office buildings, but more important than work was the thrice daily ritual of walking across the street together for "coffee." Even if you weren't a coffee drinker this was still called "going for coffee." This is a classic french tradition and became a part of my days I really enjoyed. A surprising amount of work was accomplished during coffee conversations.

So, in order that I wouldn't miss any coffee sessions I began to let people know in subtle ways whether or not I was in my office. When I left the office I closed the window blinds. When I arrived at the office I opened them. It was plainly visible to everyone from buildings around the parking lot whether my blinds were open or not. I did this consistently and people unconsciously began checking whether the blinds were open or closed to determine if I was available. As a result, I was faithfully invited to coffee.

And on rare occassion, when I really needed to work without interruption, I closed the blinds even though I was in the office. I was rarely interrupted because people assumed I was not in my office.

By being consistent, I was able to get a more consistent and predictable response from other people. The same is true with software.

The Number One Spot

In The Programmer's Code there are 27 rules. Of all these rules, why does "Be Consistent" merit the number one spot?

A few months ago I was surfing the web for information on software quality. I landed on a study performed by a major university. They were looking for things that could be predictors of software quality. Their study analyzed code samples to determine what characteristics most correlated with high or low bug rates.

In the end what they found was that the greatest predictor of low bug rates was consistent tabbing.

What? Consistent tabbing? What does that have to do with quality code? What about error management, exception handling, parameter testing, code coverage? Nope. Consistent tabbing.

[NOTE: As of this writing I was unable to rediscover the URL for this study, so if you have the link please post it in the comments below.]

What can we deduce from this? It is likely that programmers who make the effort to have consistent tabbing also make that effort in the rest of their code. Teams which have a standard style guide where tabbing is addressed likely have put energy into enforcing other good practices as well.

I don't actually believe that tabbing itself is the secret to bug free code. But I do believe that consistency is the secret to minimizing bugs.

Why Bug Rates Matter

If you're like some people, you might be thinking. So what. All software has bugs. What's the big deal?

Well, I'll tell you what's the big deal. Every year literally billions of dollars are wasted due to software bugs. And when business suffers, programmers suffer.

This article on Why Software Fails from the IEEE Spectrum does an excellent job of pointing out the actual cost of software bugs with examples from government and industry:

• The U.S. FAA blew $2.6 billion on a software upgrade to it's air traffic control system before it was scrapped.
• The U.S. IRS spent $4 billion on a new tax modernization system before dumping it.

And the examples are not just in government.

• ATT Wireless loses $100 million due to problems with a CRM upgrade.
• At CIGNA Corp. a problem with a CRM system contributes to $445 million in losses.

And the list goes on.

As a software developer, you may still be thinking this doesn't affect you. After all, you still get a paycheck even if the project fails. But there is likely a massive backlash on the horizon for the software industry. So far, I'm amazed at how deeply many business leaders' heads are buried in the sand. Software is complex and expensive yet they don't take that seriously often wanting to just get it out the door without worrying about software quality or the long term maintenance costs. This short-sighted view results in major losses. The blame often goes to particular technology leaders, consulting companies or developers. When, in fact, each company and CTO must take an active role in making sure that their software processes are good.

Without this, business leaders may start to see software as a huge risk and fewer will do it. That's fewer programming jobs.

The other possibility is that draconion rules and regulations will be put in place that ensure a minimum level of software quality, but increase costs by ten fold. None of this is good for business and therefore also not good for programmers.

Software has a terrible reputation in the business and government worlds and as programmers we need to take our role in that seriously.

The Cost of Inconsistency to Programmers

In the programming world, there are holy wars about how to use braces, how to capitalize method parameters, whether Hungarian notation is ever okay and many, many others. Why do we get bent out of shape about all of these conventions? Well, because they are conventions! One programmer likes to use braces a certain way and has a preference for that. It is difficult to read someone else's code if they do it a different way.

But what is orders of magnitude more difficult is when a single program uses multiple different conventions--which is really none at all--in the some code file. Programmer's have enough to worry about. Most programmer's have to hold dozens of pieces of information in their mind while programming. Interruptions and inconsistencies cause mental core dumps and make progress next to impossible. If I can at least trust that this entire program will use braces in the same weird way, then I can stop worrying about that. In a short amount of time, I will at least get used to it, even if I don't like it.

Another reason inconsistency in code is problematic is detecting intentionality. I'm talking about when a maintainer of code is reading the original code and trying to figure out the intent of the original programmer. There are many ways a programmer can clarify their intention in code. A comment is the easiest. Clear naming systems are another. But how often have you run across code with neither. You are left trying to guess the purpose and intent of the code in front of you. You may find yourself wondering if the code is still relevant, redundant or was never needed in the first place. You can waste a lot of time trying to figure out the original programmer's intention. And if you don't spend the time to ascertain that intention, you might be changing something that was really important.

What does this have to do with consistency? The more consistent a code file is, the more predictable it is and the easier it is to understand the programmer's intent even without comments or clear naming systems.

Conclusion

Be Consistent earns the number one spot in The Programmer's Code because it is the key feature in reducing bug rates and easing the burden on code maintainers. Bugs and code maintenance cost billions of dollars every year and billions of dollars are lost every year due to failed software projects.

Armed with that nugget of wisdom, I think it's time for a coffee break.