©Conrad Weisert, Information Disciplines, Inc.,
26 March 2006
Trade-journal articles and conference presentations are knocking down long-established practices through a clever but unsubtle deception:
Sounds naïve, doesn't it. How could anyone expect sophisticated professionals to be taken in by such faulty logic? Well, here are a few real-life examples along with brief rebuttal comments:
The End of Requirements
Last week I attended another of those requirements are obsolete presentations. After a torrent of unsupported assertions and non-sequiturs about the failures of traditional projects the speaker showed us a fragment of a sample requirements document, a diagram containing a couple of vaguely-named processes connected by an unlabeled arrow. It violated a bunch of criteria that a beginnning student learns in an introductory systems analysis course. A few in the audience tried to point out the flaws, but the speaker went on to claim that those very flaws would lead to costly rework, user dissatisfaction, and possible loss of project control. Therefore, he concluded confidently, formal requirements are at best wasted effort and at worst harmful.
Setting the record straightThe example the speaker showed would never be produced by a competent systems analyst. Furthermore, he didn't show how any alternative approach would yield a better result. This web site describes courses and offers an outline of guidance that ought to prevent such gaffes.
C programming causes buffer overflows
Various articles in popular journals have pointed out, correctly, that the C programming language does not enforce bounds checking for arrays and character strings. Therefore, it's possible to write a program that will lose control by allowing memory outside the array to be overwritten. Malicious virus programs can exploit such program bugs. Therefore don't use C.
Furthermore, the popular object-oriented language C++ contains C as a subset. A C++ compiler will compile any legal C program. Therefore don't use C++ either.
Setting the record straightWe've shown how a simple programming standard can avoid the cited danger. This is not advanced programming, nor is it difficult to implement and enforce. It's just common-sense good practice.
C++ programmers have a perfectly safe standard library class alternative.
The system development life cycle is passé
Advocates of incremental and iterative software development as well as agile methods condemn the "traditional" phased life cycle by asserting that:
Setting the record straight
No serious practitioner or manager actually tries to follow such an inflexible approach, nor has the so-called waterfall model ever been proposed by any respected expert.
We could go on and cite more examples of this growing technique, but you get the idea. Discrediting today's "traditional approach" has become an expected part of introducing tomorrow's new approach, even if one has to rely on distorted examples of incompetent misuse. When we hear or read such assertions, let's challenge the sources to set the record straight.
Return to IDI home page
Last modified March 31, 2011