[From Pitfalls of Modern Software Engineering by Bruce F. Webster (forthcoming)]
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.
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.
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.
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.
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.
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.
Webster, from Pitfalls of Object-Oriented Development (1995).