Mixed benefits from methodology breakthroughs . . .

If it ain't broke, fix it anyway

by Conrad Weisert
July 23, 2005, (revised May, 2006)
© 2005 Information Disciplines, Inc.

The failed promise of major dramatic breakthoughs

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

• we are now developing software with less than 1/1000 the effort it would have taken in 1960, or

• we are now developing software three orders of magnitude more complex than we'd have dared to undertake in 1960.

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.

Why?

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.

• Some organizations may have expressed a commitment to a breakthrough methodology, but then backed away from embracing it fully. For example, many organizations that claimed to be practicing structured programming in the 1970s insisted nevertheless on continuing to write programs in an ill-suited language, Cobol, and, worse, to organize their code into huge monolithic main programs.

• Some fad methodologies provided little real benefit and may even have undermined previously established best practices. For example, many organizations trying to follow the use case approach to system specification have experienced a serious requirements crisis.

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.

Which MDBs?

Let's review some MDBs of the past decades, classifying them in two ways. For each major dramatic breakthrough, we'll note:

1. Whether the new methodology component is
   • evolutionary, building on established good practice, or
   • revolutionary, demanding that practitioners abandon current practices.

2. Whether the MDB¹
   • is likely to yield significant benefit, or
   • offers little real benefit and may even have a negative impact.

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.

The discredited traditional approach

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.

Growing intolerance and age discrimination

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.

Ignorance

Not surprisingly, intolerance is often paired with ignorance. Some³ 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:

• Thorough unit testing is an agile innovation.

• Component reuse was impractical (or impossible) before object-oriented programming.

• Java is the first language to include multi-threading as a built-in feature.

• The Y2K crisis arose because:
  1. COBOL required a six-character date representation.
  2. Storage was too expensive to support a more sensible representation.

• In Java, unlike C++, everything is an object.

• Under a phased life cycle, specifications are frozen.

Younger audience members including managers nod in agreement and sometimes take notes. Note that each of the above misstatements was about fact not opinion.

Bottom line advice for managers

Neither tradition nor innovation deserves unquestioned acceptance. Newer doesn't mean better; neither does tried and true.

• To embrace uncritically the latest major dramatic breakthrough in software development methodology risks not only disruption due to change but also the possibility of replacing something that works (or can with management discipline be made to work) well by a less effective process.

• On the other hand to reject or ignore current developments, risks missing out on a genuine breakthrough in productivity and quality, as well as losing competitive advantage.

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:

• Be aware of the latest MDBs. Send a staff member to a vendor presentation or short course, or bring an outside expert in for an in-house presentation. (But beware of the brainwashed staff guru who wants to convert your shop immediately to the fad he or she has just learned.)

• Demand a higher standard of justification for revolutionary methods than for evolutionary ones, especially if your current methods are producing satisfactory results.

• Don't let yourself be intimidated by superiors, by peers, by subordinates, or by vendors. An organization that has deliberately chosen to forgo the latest fad or to retain successful methods is not backward.

• Be particularly suspicious of "experts" who strongly favor the same solution for every problem.

• Favor flexibility over rigid miltary-style standards and processes, especially if yours is a decentralized organization.

³ -- 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