How to save $80,000 a year at a cost of millions

Share This Post

Share on facebook
Share on linkedin
Share on twitter
Share on email

How to save $80,000 a year at a cost of millions

We have, of late, heard a lot of whining about programmers extorting money from former employers to prevent various bad things from happening. As it happens, in a well-run shop this is a very easy problem to avoid: All you have to do is have a clear set of coding standards, and some competent person who enforces these standards.

What does this mean? Well, the first part is fairly self-explanatory: Someone must come up with coding guidelines appropriate for each language or tool used. Within our experience this is relatively easy to do. The three objections we usual hear about coding standards are that they are arbitrary, that many tasks can be performed in many ways, and that fixed standards stifle the flow of the Muse or programming. To which the appropriate answer is “so what?”

In truth, there are many ways to do many tasks in programming, and different programmers favor different approaches. However, in most cases the differences are differences in style, and no one approach is generally significantly better than any of the others. This means that if, for each task where multiple techniques are used one is, arbitrarily, chosen, every time that technique is seen in the code everyone will immediately know what is being done, rather than having to waste time trying to figure out what the programmer was trying to do.

Does this, in fact, stifle the flow of the Muse of programming? Our experience is that once programmers overcome their usual resistance to coding standards, they discover that they are freed up to think about what they are trying to do, rather than which of many equivalent pieces they should choose, and that they become more productive.

In addition, when every programmer is using the same tools to do the same tasks, the programs become somewhat more self-documenting, as they use a common set of coding idioms. Which does not mean that commenting the code is unnecessary, Indeed commenting requirements need to be part of the coding standard, as readability is, in the long term, one of the most desirable qualities of computer programs.

Unfortunately, the motto of the computer world is “Never time to do it right; Always time to do it over,” and there is a tendency, since many projects are either a rush, or prototypes which mysteriously remain in production for years, there is a tendency to ignore coding standards just this once — as well as every other time.

Because of this, it is critical that someone high up insist that coding standards be established, and that someone, or some group, review every piece of code for clarity, documentation, and compliance to standards.

When there is a code Gestapo in place, it virtually eliminates the traps that disgruntled employees might build in: The code simply won’t be released until it is understood, line by line. As a side benefit, it also assures that the code is readable, both of itself and through its internal documentation, which will greatly reduce the cost of maintenance down the road.

More To Explore