Standards in Software

In the preface to the "influential" computer science book Structure and Interpretation of Computer Programs, the authors, Harold Abelson and Gerald Jay Sussman of MIT, put forth the above idea as a way to express to their students that the art of writing software is as much, if not more, about expressing ideas in a methodology as opposed to simply providing a set of instructions to a computer. Personally, I like this quote because it helps drive home the idea that as software engineers, we "write" software much like a screen writer develops a screenplay for a movie: we have two audiences. One audience, most obviously, is the group of users of our programs. But another audience, and the more critical of the two, is the group of software engineers who will be tasked with maintaining our creations and producing future revisions with new and more complex features. Likewise, screen writers must have their work interpreted by actors, directors, and cinematographers who will hopefully put together a quality movie based on a compelling underlying story.

It's instructive that this is written in the preface to a book that is the text for introductory coursework in computer science and programming in general -- it's clearly a fundamental idea. After 25 years as a professional software engineer in commercial environments, I have found that the idea is very often "under appreciated."

A year ago I attended a lecture by Scott McNealy, former CEO of Sun Microsystems and open-source advocate, where he made the following observation: it often took his programming teams longer to develop a piece of open source software than a proprietary closed source equivalent. The reason? Programmers were more concerned that their open source software would be seen by a wider audience of their peers and thus took more care in its composition.

This is an interesting observation because it seems to reinforce our opening quote: programs are written for people to read ... and it provides the reason that software standards are important. Incidentally, it also provides a signpost that differentiates higher quality engineers from lower quality -- engineers lacking discipline will struggle with the required innate attention to detail. In much the same way a good story depends on a good storyteller, a good idea expressed poorly in software will often struggle to win in the marketplace.

Software standards make it easier for people to read programs.

For me, the primary attribute of well-written software is the almost excessive use of comments. Comments in the source code are not meant to restate that which should be obvious in the code, but instead to communicate the reason the code exists, its ultimate objective (as much as a way to help ensure its correctness and completeness as anything else), its role in a bigger picture, and its unseen side effects. I have always found that comments are a good place to include some history, arguments about alternative designs, and sarcasm. It's important to keep your readers awake.
In conjunction with well-written comments is code simplicity. I think it was Einstein who said that things should be as simple as possible, but no simpler. Software that is more complex than necessary, even if intended to be more efficient, introduces many potential problems: future readers of the program are at greater risk of misinterpreting the original author's intent; it becomes harder to validate that the code implements the ideas expressed in related comments; and it may prevent a compiler from implementing more beneficial optimizations. Famous computer scientist, Donald Knuth, once said, " Premature optimization is the root of all evil (or at least most of it) in programming."
Due to the shear size and complexity, most software is written by teams of people working together, sometimes over vast distances, time zones, and cultures. Enforcing standards for programming structure and style eliminates many things that distract from the objective of correctly expressing the proposed architecture.

The case for standards in programming style is strong and fundamentally good, but the enforcement, as with all rules, should be flexible and thoughtful -- rules cannot replace thinking. I have witnessed teams of engineers spending obscene amounts of time putting together standards documents, arguing over minute details, all of which could be adopted from pre-existing published standards from various organizations, only to fail in the enforcement stage. It's all too common for standards simply not to be enforced at all, mostly out of a personal fear of insulting a peer. Even worse though, is the strict adherence to a convenient standard whose application in any given situation might actually detract from the "telling of the story." The highest priority for standards in software must be to preserve the quality of the expression of the underlying methodology. Programs must be written for people to read, and only incidentally for machines to execute.