by Conrad Weisert
July 23, 2005, (revised May, 2006)
© 2005 Information Disciplines, Inc.
The past fifty years have seen a succession of major dramatic breakthroughs (MDB) in software development tools and methodology. Occurring roughly every three or four years, those MDBs have each promised an improvement in programming productivity ranging between twenty percent and an order of magnitude. If those expected benefits had all been realized, then either
Although today's application software is undoubtedly more complex than typical applications of the 1960s, few developers and even fewer users claim a factor of 1000. Besides, much of the growth lies in fancy user interfaces rather than in what the applications actually do. Organizations report that out-of-control projects wasting years of time and millions of dollars are as common today as they were a generation ago. Methodologists, trying to persuade us to adopt theit latest fad, concur.
It follows either that the promised benefits of each MDB were wildly exaggerated or that software-development organizations have consistently failed to adopt the new approaches in letter and in spirit. Both explanations are responsible for the ongoing disappointment.
Although both problems are hard to overcome, the first will eventually yield to staff education and management discipline. The second poses the greater danger, as methodology gurus intimidate practitioners into substituting the latest fad for techniques that have worked well. This article, therefore, will focus on the methodologies themselves.
Let's review some MDBs of the past decades, classifying them in two ways. For each major dramatic breakthrough, we'll note:
|1957||Fortran||Revolutionary||Enabled engineers & other non-programmers to solve their own problems.|
Demonstrated practical code optimization.
|Inhibited large-scale modular program organization.
Facilitated loss-of-control bugs.
|~1959||Reusable components||Evolutionary||Lowered cost of development and maintenance, especially debugging; encouraged standardized approaches||(See note 1)
Adoption very slow by business application developers
|1961||COBOL||Revolutionary||Large productivity gain in initial development over assembly languages||Encouraged a monolithic programming style leading to high cost of future maintenance; inhibited reusable components and (later) structured programming|
|1964||PL/I (& other Algol-like languages)||Evolutionary||Encouraged modular program structure; supported modern technology such as multithreading.||Costly to implement; perceived as hard to master.|
|~1967||System Development Life Cycle (SDLC)||Revolutionary||Limited risk of losing control; empowered sponsoring user organization||(See note 1)|
|~1969||Structured coding||Evolutionary||Lowered maintenance costs by making source code much easier to understand and modify||(See note 1)|
|~1971||Structured design / top-down refinement||Evolutionary||Facilitated modular program structure||(See note 1)|
|~1976||Online development||Evolutionary||Eliminated impact of turn-around time on testing||Encouraged expedient short-cuts that compromise quality||~1978||Structured analysis||Revolutionary||Addressed "requirements crisis";
clarified role of systems analyst;
eliminated confusion between analysis and design
|(See note 1)|
|~1980||Relational data model||Evolutionary||Normal form helped simplify database structure;
Views helped separate program logic from database design
|(See note 1)|
|~1984||Non-procedural languages||Evolutionary||Empowered end-users to bypass development services||Some user orgs. became dependent on unsupported and undocumented programs|
|~1987||Event-driven paradigm (with GUI)||Revolutionary||Facilitated consistent user interface||Diverted emphasis from what an application does to how it looks|
|~1990||Object-Oriented Programming||Evolutionary||Enforced highly modular program structure; encouraged reusable components||(See note 1)|
|1993||UML||Revolutionary||Standardized object-oriented graphical models||Resurrected requirements crisis|
|1995||Use cases||Revolutionary||Attempted to overcome UML requirements deficiencies||Undermined structure in system specification|
|1997||The Java Platform||Revolutionary||Facilitated Internet application deployment||Imposed complexity on some formerly straightforward programming functions; promoted distortions of object paradigm|
|2000||Extreme Programming (and other so-called "agile methods")||Revolutionary||Fast development of single-program applications with heavy sponsor participation.||Undermines packaged application software solutions|
Note 1: A persuasive case can be made that those seven MDBs, when practiced by well-trained practitioners, impose no drawbacks and are still considered non-controversial enlightened good practice.
Veteran software developers have noticed a striking phenomenon: Each major dramatic breakthrough becomes tomorrow's traditional approach. I recall listening in the early 1970s to presentations contrasting the phased life cycle with "the traditional approach", and just a few years later learning how structured analysis would solve the requirements crisis that had characterized "the traditional approach". Today, it's rare to attend a presentation on UML or agile methods that doesn't contrast those new methods with "the traditional approach", by which they usually mean the phased life cycle and structured analysis.
Alas, in our profession tradition is often seen as a bad thing. When a methodologist uses the term, he or she implies a dismally unenlightened disorganized and undocumented mess. In a 1980 structured analysis course the instructor advised the students to begin the analysis phase by documenting a model of the current system. When I asked him how that step should be done if the current system was already well documented, he was astonished. He simply couldn't imagine a well documented system that pre-dated structured analysis. A quarter-century later, fad methodologists cannot imagine how a "legacy system" could possibly be well organized and coherently documented.
In the past dozen years, advocates of new methodologies have moved on from mildly disparaging characterizing of the current so-called "traditional approach" to rather mean-spirited condemnations of established processes and of the people who practice them. Procedural programming, they point out, was done in dinosaur languages most likely by dinosaur programmers. They sneeringly condemn the phased life cycle as a bureaucratic and hopelessly inflexible waterfall approach. People who insist on practicing it are characterized as dismally unenlightened if not "brain-dead".
We encounter those attitudes toward mature professionals not only in meeting forums, but even in articles and books written by fad methodologists. A nasty example is reviewed on this web site.
Those attitudes add much fuel to the age discrimination felt today not only by those over, say, 55, but increasingly even by 39-year-olds. Why would a manager want to hire a dinosaur who rejects or cannot learn modern methods? Recruiters are counseling job applicants to omit experience with COBOL and other pre-1985 technology from their résumés.
Not surprisingly, intolerance is often paired with ignorance. Some3 of the methodologists who specialize in the latest MDB are shockingly unaware of what came before and how the software development field has evolved. Among the misinformation I've heard in presentations by experts are the following:
Younger audience members including managers nod in agreement and sometimes take notes. Note that each of the above misstatements was about fact not opinion.
Neither tradition nor innovation deserves unquestioned acceptance. Newer doesn't mean better; neither does tried and true.
The sensible course, then, for a modern software development organization, is to let your methodology evolve in the normal course of your projects. A participative approach in which a knowledgeable professsional staff proposes incremental changes to the organization's standards and processes will yield a good balance between stable and up-to-date methodology.
Here are a few recommendations:
2 -- The years are approximate, reflecting the time at which a sizable body of professional and trade literature publicized the methodology as a major dramatic breakthrough. If you have a more exact date, let me know.
3 -- Of course, many of our methodology expert colleagues exercise sound judgment. My criticisms here are aimed at what I believe (and hope) is a small (but awfully loud) minority of methodology gurus.
Return to Management articles
IDI home page
Last modified October 6, 2010