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:
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:
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:
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.
Return to management articles
IDI home page.
Last modified June 22, 2011