Subscribe via RSS Feed

Pitfall: Thinking a new techology or methodology is mature

February 28, 2008 1 Comment

[From Pitfalls of Modern Software Engineering by Bruce F. Webster (forthcoming)]

CATEGORIES: conceptual

OK, the pitfall title itself may be something of a giveaway, but stop and think: how often does a new technology or methodology (”the TOM”) emerge, only to have IT departments (or their executive overseers) seek to adopt the TOM for time-, budget- and/or mission-critical projects? These organizations expect that the TOM will be stable, reliable, standardized, well-documented and fully supported — that is, mature – without realizing that few TOMs have been in constant use long enough to have reached that status.

When Pitfalls of Object-Oriented Development came out in 1995, it noted that object-oriented languages had been around for about 25 years. Yet object technology at that time, as applied to production-grade projects, was still largely a young and somewhat narrow field, especially compared with the well-hammered and heavily used structured development TOMs.

The same is true today and likely always will be. New, variant, or derivative TOMs emerge in a steady stream, reflecting both necessity and invention and offering (usually) key benefits and improvements over the old TOMs. In other words, a new TOM may well have compelling benefits — but that doesn’t mean that it’s mature (as defined above).


Lack of concern over tools to be used; persistent problems integrating tools, methodologies and the new TOM; heavy dependence on tools from a single vendor; having to work around tool and methodology deficiencies.


Discovery, often late in the schedule, of design and implementation gaps; major schedule slips.


Make a list of all forms of the TOM being used in your development effort: methodologies, architectural concepts, CASE tools, languages, diagrams and notations, class libraries, patterns, design and implementation strategies, and so on. Analyze how well they fit together. Get evaluations from all those who use (or should be using) these technologies.


After doing the evaluation listed in Detection, reset expectations appropriately. Then look for ways to fill the gaps and strengthen the weak spots.


For starters, assume that the TOM isn’t mature and factor that into your project plans. Make a preemptive list of technologies to be used and evaluate ahead of time how stable and comprehensive they are and how well they’ll fit together. Fill the gaps ahead of time, either through proper selection or through home-grown solutions. Proactively manage both risks and expectations.


Webster, adapted from Pitfalls of Object-Oriented Development (1995).

About the Author:

Webster is Principal and Founder at at Bruce F. Webster & Associates, as well as an Adjunct Professor for the BYU Computer Science Department. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at 303.502.4141 or at

Leave a Reply

You must be logged in to post a comment.