Deliberate deceit or ignorance?

False Phases Used to Try to Discredit Life Cycle

by Conrad Weisert
January 13, 2011

©2011, Information Disciplines, Inc.
This article may be circulated freely, as long as the copyright credit is included.

I attended another one of those "agile" presentations yesterday in which the speaker tried to discredit traditional system development by asserting ridiculous straw-man characteristics that no sensible individual or software development organization ever advocated. Whether her claims stemmed from deliberate mischaracterization or from simple ignorance was unclear, but her mis-use of the term waterfall suggested the latter.

After echoing the common canard about some huge percentage of non-agile projects exceeding their initial estimates by some huge ratio, the speaker began by contrasting the sequence of these four activities:

Requirements Design Coding Testing

under traditional and agile approaches. Under the traditional approach, she informed us, a project team does all of each of those before starting to do the next, while under an agile approach we do a little of each incrementally throughout the project!

Sorry, I've never worked on a project in which we did all of the design before doing any coding, or wrote all the code before doing any of the testing. That would be a serious violation of the spirit and practice of either top-down or bottom-up modular development.

I admit, however, to trying very hard to get users' requirements1 agreed upon before charging off to build software. Eliciting, organizing, and documenting those requirements is the primary role of systems analysts as contrasted with programmers2. The "agile" crowd relies on two shaky claims to try to persuade us of the futility of preparing system specifications:

  1. It's impossible to know everything about requirements for a new application system or to elicit them from naïve user representatives before the users have had a chance to see actual working software and interact with it.

  2. Even if we could, the requirements are sure to change before the system is built and deployed, based on changing business environment, fresh insights, new technology, or error correction.

There's enough plausibility there to get our attention, but neither is a valid excuse to abandon the most important phase in the course of a development project. A mature and responsible systems analyst responds to the above:

  1. We may not get the requirements 100% perfect, but we do the best we can based on the best knowledge we have. The more complete and correct the specifications are, the more predictable the cost and duration of the development and the quality of the results will be.

  2. We never freeze the specifications. Changes that come to light during the later project phases can be priced, prioritized, and justified in the normal, rational way.

Of course, any methodology works if the project is small enough or if the budget and schedule are relaxed enough. But that's not the environment in which most applications are developed. Bypassing rigorous specifications in favor of a wishful-thinking incremental approach is a reckless strategy for any serious non-trivial development project. No responsible manager would consider it.

1—also known as "functional specifications" or "external design".
2—now often called developers by those who don't fully understand what they do.

Return to management articles
methodology articles
IDI home page.

Last modified June 22, 2011