It's the end-product that counts . . .

Programming Standards Should Emphasize Results

Conrad Weisert, 20 May 2011
©2011, Information Disciplines, Inc.

NOTE: This article may be reproduced and circulated freely, as long as the copyright credit is included.

Experienced professionals know that maintenance accounts for a massive portion of the cost of custom software. We therefore embrace programming standards that assure the maintainability of the programs our staffs develop. We hope those standards will assure that:

Such standards will apply almost 100% to the end products, i.e. the actual deliverables, not to the processes that may have produced them. When we assess the quality of a program, we examine the source code and, if necessary, any supplementary design documents, but at that stage we no longer care how the programmer(s) produced it.

In particular, once we have in our hands a finished working program, it makes no difference:

Of course, the issues we don't care about now were important when the program was being developed. They may have had a huge impact on the schedule, the meeting of customer commitments, and sometimes success in a competitive marketplace. Those were critical concerns for the project manager. But all that is over now.

Procedural methodology prescribing development activities has a one-time impact. That impact may be so large as to affect the justification for doing the project, but once the end product is developed they have no further impact.

On the other hand, quality standards prescribing the end product itself have a continuing and repeated impact over the life of the product. That impact affects cost, competitive success, reputation, and sometimes the very existence of an organization. Therefore:

Programming Standards Manifesto

  1. Favor standards that specify what is to be produced over procedures that specify how programmers are to produce it.

  2. Emphasize reviewing deliverables and enforcing quality standards over monitoring activities.

  3. Trust the project managers and professional staff, especially in remote locations, to produce what they've agreed to produce, following whatever procedures work for them.

Finally, be wary of the methodology guru who is obsessed with procedural issues and expresses contempt for the unconvinced. You'd be surprised how many of them turn out poor, even atrocious programs.

Last modified 25 May 2011

Return to IDI home page
Technical articles
Methodology material