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.

Introduction

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-cycle¹ methodologies (SDLC), specifying a sequence of phases from initial conception through installation and operational start-up:

• Some of those SDLCs were primarily activity oriented. That is, they specified a sequence of model tasks to be performed by the project team under the direction of a project manager. If a project team faithfully followed that sequence, the organization would not risk an out-of-control project, and the outcome would be at least moderately successful.

• Other SDLCs were primarily results oriented. They specified what was to be produced in each phase (the "phase deliverables") without constraining² how the project team was to produce them.

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:

• pair programming
• test-driven development (TDD)
• emergent design
• rigid release schedule ("sprints")

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:

• An organization's written methodology³ should specify in sufficient detail the characteristics of the deliverables projects are expected to produce.

• Its internal education program should prepare less experienced programmers for producing such products. Courses and coaching may also offer guidance on methods and techniques but should carefully distinguish among mandatory standards, recommended conventions, and helpful guidelines.

• Its quality review function must focus exclusively on tangible and visible results and should not concern itself with the processes that may have produced them.

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.

Return to table of contents
management articles

Last modified May 27, 2010