4 Often Forgotten Programming 101

Much, if not most, of the functionality in products today is provided by software, some evident, some embedded. As such, you will spend a disproportionate amount of your time finding and correcting software defects in your new developments. A much better approach is to preemptively attack this issue by developing, promulgating, and enforcing documented software design guidelines. Some companies literally have hundreds of pages of such guidance, but one has to wonder if it is more to impress the ISO-9000 auditors than to help the staff. We recommend that you again stick with the basics, two to five pages at most that your staff might periodically reread, and focus on the poor practices that cause the most schedule delays.

Internal software design guidelines should focus on architectural and design issues, rather than style or format. While the latter offer some improvement in reusability and maintainability, one will rarely encounter a time that they cause large program delays. On the other hand, failing to comply with the following groundrules will resurface painfully and frequently in most organizations that are developing software as part of a system project or product. They are listed in order of pain or payoff, depending on your perspective.

Several staff will resent your hammering home these groundrules, but do it anyway…, repeatedly. The responses are along the lines of “Who is this new boss that is nagging us about these simple rules? Everyone knows them.” Yes, but everyone also seems to violate them far too frequently. This list has changed very little over the last twenty years.