The Cost Risk of Programming Standards

I was going to open this month's blog entry with the famous quote from Andres S. Tannenbaum: "The nicest thing about standards is that there are so many of them to choose from." But the problem with standards is not how many of them there are but how to you chose what standards to adopt.

In last month's Lone Coder, "Bad Docs or Adventures in Linux RAID-land" (Lone Coder), a received an email from someone who said that there were so many ways to lose data--including theft, fire and storms--that protecting the integrity of the data was a waste of time. I'd respond by asking what the probabilities are. With terabyte drives and millions of data blocks containing a lifetime of personal information, the odds of getting corrupted files over a decade is nearly 100%. The odds of theft, fire or storm damage may be 1%. It's a matter of understanding the risks.

In regard to programming standards, each person learns his or her own practices as a product of their life experience so that no two programmers write source code in exactly the same way. Someone who uses a lot of assembly language, or systems programming, or web programming may develop certain habits that reflect the environments they worked in. The same is true of using certain programming languages or going to a particular university or working in a certain country. There was a study done--I don't have the citation--of programming styles from different countries and it showed that the programmers valued speed, quality or elegance of design in different proportions depending on the country. North American programmers often favour speed--most lines for the least money--over quality or elegance, for example. I alluded to some of these issues in the article "Clean Code: Agile Handbook or Engineering Attack" (Lone Coder).

Risk assessment defines risk and cost times probability. If a fire will cause $1000 in damage and will occur every 500 days, then the risk represented by the fire is $2 per day. A person should budget no more than $530 a year to prevent such a fire because any more would mean spending more money than it would cost to clean up after the fire. Of course, this kind of assessment requires an accurate assessment of the risk and the cost.

When a companies grows and there are a large number of developers, standards need to be enforced. This is especially true if there are junior programmers around who haven't had the experience to develop good practices. But what is the goal of having standards? Risk management suggests a set of minumum standards which reduces the maximum risks. Enforcing complex standards means wasting a lot of energy on low-cost issues (besides the risk of creating a "lowest common denominator" set of requirements--standards that are almost always inappropriate for every kind of task because they are too detailed and too generic). Having no standards at all means leaving your organization in a state of anarchy where, in the worst case, following someone's programming means reviewing each and every line of source code.

For example, I spoke with a PHP developer recently who complained about horrible code. I asked about it. He explained that the programmer had a long string literal and he had broken the string up using concatenation into screen width sized pieces. Something like this:

    $a_very_long_string = "This is a really long string.  It's so long that " .
       "it's broken onto two lines.";

The developer was concerned about the loss in performance. I told him that PHP probably optimized the constant concatenations away when it loads the program, and even if it didn't, the performance loss risk was probably minimal when compared to the risks posed by poor readability. Was the code really "horrible" or was it a case of not accessing the risks?

Unfortunately, creating standards in many companies...particularly ones created without a knowledge or understanding of the how to create standards...often leads to a goal of creating the ideal program look or using the most popular approaches used rather. For example, in making a standard, is a survey made of how many recorded bugs are reduced by a new standard? How is the importance of a particular standard tied to the dollars in costs or benefits to a company?

For example, considered the war of tabs versus spaces for indenting. People who use spaces over tabs often come from backgrounds in text-only environments, systems programming or other environments where tabs are inconsistent. People who prefer tabs usually are familiar with GUI tools. Isn't the real question whether or not the program can be readily understood? If so, then tab or space indenting has low risk since they look essentially the same. Jeff Attwood argues in "Death to the Space Infidels" (Coding Horror) that a team must adopt either spaces or tabs as a standard because of the costs to the company when programmers must switch between the two types of indentation. I, personally, switch easily from tabs to space, so how much cost savings is there really?

On the other hand, typecasting all your integer database column values into PHP integer values prevents the type meta-data from being lost, protects against corruption when types are mixed, and makes those values behave in a consistent manner throughout a program. All it takes is an int() or intVal() function call. So that's high reward for low effort. That's a good risk trade-off.

I read one PHP standard that denied the use of loop-exiting statements because all loop exit conditions had to be written in a massive expression in the loop control statement. That makes reading the program more difficult and increases risk.

Jeff Attwood also says "The only programming project with no disagreement whatsoever on code formatting is the one you work on alone." Habits are learned behaviours that occur without thinking about them, often unnoticed by the people who have them. With some programmers, their habits become a tradition, something they associate with part of their identity. Attacking those habits may make them feel threatened, especially if they're under a lot of stress to get work done. A team leader may be more likely to promote his own programming habits as a standard because it's comfortable for the leader to adopt them. How many habits does a leader want to fight by imposing an overburdening standard? You may spend all your time fighting minor coding habits while bringing nothing of value to your company. Rather than creating a monolithic standard, perhaps a more human, more targeted, easier to follow and understand standard will produce good value with low cost.

And, of course, heavy-handed standards suggest that you don't have faith in the capabilities and judgment of your team. Either you have a weak team, or you are a weak team leader. For example, saying "after 3 elseifs, use a switch" shows a lack of confidence in your people, and that an arbitrary decision makes more sense than a decision made in context (what if there are 4 elseifs...is that really bad?). Either way, the problem cannot be solved with a standard.

Any good standard is also a living standard, one that takes people, projects and contexts into account.

Good areas to standardize on are:

• file names and directories (to be able to locate things)
• placement of "include" directives and variable declarations (ditto)
• comment placement and contents (to know the purpose of programming in a file)
• known programming language weaknesses causing serious errors (such as PHP's typing system)

That is, to paraphrase a computing maxim: keep your standard simple, stupid.

April 30, 2009