Emphasis on process can be harmful . . .

Results Are the Primary Concern of Methodologies

by Conrad Weisert
May 14, 2010
©Information Disciplines, Inc.

This article may be circulated freely as long as the copyright notice is included.


We've been hearing vigorous debates lately about the pros and cons of recent fads in software development. Surprisingly, many of those debates focus on the process and pay little or no attention to the results that are produced.

To avoid arguments, I try to get the enthusiasts to concede that there are four possibilities:
A good process (one that we like and admire) can yield a good result
a bad result
A bad process (one that we hate and disparage) can yield a good result
a bad result
There's never any argument about the first and fourth possibilities. Some of our colleagues, however, are doubtful about the second and third. In an earlier article we met Jerry the brainwashed young programmer, who couldn't bring himself to concede that the latest major dramatic breakthrough in software development metholodgy might not be the only workable practice. Jerry was a fictional character, but we're encountering more and more real closed-minded doctrinaires in today's software development organizations.

Background: Life Cycle Methodologies

The 1970s brought the publication and selling of formal application system development life-cycle1 methodologies (SDLC), specifying a sequence of phases from initial conception through installation and operational start-up:

For organizations that practiced a high degree of professionalism the results-oriented approach tended to yield more successful projects and higher staff morale.

Application to programming

Recent fads in programming methodology have focused less on the resulting program than on the activities (or process) by which the program is produced. In many cases, that's a misguided emphasis that may seriously compromise the quality of our software. Those processes include cornerstones of the so-called "agile" methodologies, such as:

Those are indeed intriguing and potentially useful techniques, but a company standard requiring their use on projects misses the main point of having standards, which is to assure high-quality application systems. If a piece of production software was produced by pair programmers practicing test-driven development, that's irrelevant if the end product is superb and irrelevant if the end product is atrocious. If it was produced by a single programmer doing bottom-up development at home in the middle of the night, that's irrelevant, too.

Management view and recommendations for an organization

Very few managers have any interest whatever in the processes that their I.T. department or contractor follows. They care about results: A new application system needs to solve the right problem at an acceptable cost at an acceptable time. It also should have a trouble free future, not only with respect to reliability and operational performance, but also with respect to flexibility and maintainability.

Therefore, an organization's I.T. infrastucture must emphasize results. In particular:

Build your staff from top performers. Tell them exactly what they're expected to produce and trust them to choose the best ways of producing it.

More to come

In coming months we shall explore the downsides of certain fad techniques as they affect software quality.

1—Sometimes erroneously called the waterfall model.
2—The methodology documentation might suggest or recommend a process or activity.
3—the successor to the old standards manual, now usually deployed as internal web pages.

Return to table of contents
management articles

Last modified May 27, 2010