Programming: Standardization & Uniformity
By Russ Finney
Ralph Waldo Emerson one said "a foolish consistency is the hobgoblin of little minds", and this advice still holds true for project team leaders. The benefits of standardization should not be so rigorously enforced that potential time saving and innovative fresh approaches are suppressed. Once again the key word here is: balance.
Two extremes seem to exist within projects at companies with system building experience. One approach is to do everything in a new way, making everything up as the system is built, never looking back to previous successes. Another is to religiously follow established patterns of uniformity, never allowing new ideas to be introduced, always doing everything the same way. Most companies fall somewhere in between. The optimal approach is to begin with the existing standards as a baseline, and then to review, discuss, revise, and implement each throughout the system building process.
Another unreasonable focus can be on program efficiency and processing speed, rather than on program modularity and maintainability. This is a mistake. With the availability of today's highly advanced technical platforms, no one really cares anymore if it runs in 20 instead of 80 nano-seconds. This is especially true for business programmers. The emphasis should be on structure, reusability, and ease of understanding. The business system builder's philosophy should be rooted deeply in these quality and excellence ideas:
- The system should be coded as if no one on the team will be around in two years to help with the maintenance.
- The system should be coded as if everyone on the team will be on call at three o'clock in the morning to solve any processing problems.
- The system should be coded so that anyone who will be unfortunate enough to really get a call at three o'clock in the morning will be able to quickly and efficiently understand the programming approach and logic.
- The system should be coded so that once a programmer becomes familiar with just a few of the programs, all the others begin to look the same. A maintenance programmer should be able to depend on this consistency.
- The system should be coded as if it were becoming a business asset, not someone's personal creative outlet.
Copyright © 1999, Russ Finney, All Rights Reserved