Pitfall: Confusing tools with principles

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

CATEGORIES: conceptual

Using tools designed for a given technology or methodology (”the TOM”) does not mean that the project will follow solid TOM principles, any more than sitting in (or even driving) an Indy-class race car qualifies you for the Indy Racing League circuit.

Many projects using a given TOM-specific tool reflect no real concept of the principles underlying the TOM. In many cases, they reflect no real understanding of professional software engineering in general. Yet using these tools can lead all involved to believe sincerely that they making proper use of the TOM.

Many paths can lead to this situation — upper-level mandates, enthusiastic tool adoption, project rescue attempts — but the root cause is insufficient information and experience.

Symptoms

Engineers, architects, and managers saying, “Of course it’s [TOM]-based: We developed it using [a TOM-oriented tool]!” Beyond that, many of the pitfalls described in this book are indicative.

Consequences

For starters, you tend to lose the benefits of the TOM itself. Beyond that, the project may actually take longer than it would have if approached as a non-TOM project using classic, well-established techniques of familiar technologies and methodologies.

Detection

Conduct reviews that ignore the tool(s) in question and focus instead on the relevant aspects of the project. These reviews should focus on key deliverables that indicate whether the core TOM principles are actually being followed. See whether anyone actually has these deliverables available or can create them on short notice. See whether they make sense.

Extraction

If your review turns up serious problems, then halt current development and take the time to evaluate your choices: Either push ahead to completion or rethink, redesign, and re-implement. All the political and financial pressures will point toward the first solution, but it may end up leading to project failure. The second solution is not only more likely to result in a better application it also may get you to completion more quickly.

Prevention

Education and experience are the keys. First, the key managers, architects and/or developers should have a solid grounding in principles of the TOM in question. Ideally, they should have actual experience, but if your group is just converting to a TOM-based approach, you may end up in a “learning by doing” situation.

Contributor/References

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

About the Author: bfwebster

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.