Software Design & Engineering Internet business development mobile applications |
Alan Partis |
320 Ridgecreek Drive Lexington, SC 29072 (803) 692-1101 alpartis@thundernet.com |
|
|
|
Standards in SoftwareFebruary, 2013"Programs must be written for people to read, and only incidentally for machines to execute." 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.
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. |
"Thundernet" is a trademark of Thundernet Development Group, Inc. a Florida corporation. |
Copyright © Thundernet Development Group, Inc.. All rights reserved. |