Subscribe via RSS Feed

Pitfall: Confusing approach with results

April 26, 2008 0 Comments

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

Categories: conceptual, political

Native tribes in the South Pacific developed “cargo cults” during the middle part of the 20th century. Having observed planes (such as the venerable DC-3) landing on their islands and discharging goods from inside, these tribes created simacrula of the planes and worshipped them, sure that goods would magically arrive as a result.

Something similar happens with many projects that are used to pioneer a new technique or methodology (the “TOM”). Those in charge select the TOM, possibly with supporting tools and technologies, and the team pushes ahead. Having gone through the motions and used all the right tools, the team and its upper management may presume that what they’ve created is properly in line with the TOM and as such will incur all the benefits thereof.

Unfortunately, what often results bears little resemblance to best practices — or even somewhat OK practices — in professional TOM development. The painful reality is that they are in many cases worse off than if they had simply used existing techniques, methodologies and languages.

Symptoms

Serious problems in schedule, functionality, and quality. Failure to achieve expected benefits of object technology.

Consequences

Project instability and schedule slip, often ending in partial or complete project failure.

Detection

When you raise issues concerning what is being (or not being) created, you get responses of “But we’re using [methodology/notation/language/technology]!” When you probe for actual understanding of TOM development within the project, you quickly run into blank stares, defensive attitudes, and canned answers.

Extraction

This is a hard one to push through to completion. In most cases, what you have to do is bring in some technology and process mentor; in far too many cases, you have to throw out everything that has been done so far and start over.

Prevention

Ensure that the development team has people on it who really understand the technology or methodology and who have the skill and experience to apply it correctly and successfully.

References

[Professional experience]

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 bwebster@bfwa.com.

Leave a Reply

You must be logged in to post a comment.