Pitfall: Confusing buzzwords with concepts

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

CATEGORIES: conceptual

Every technology or methodology (“TOM”) has its own jargon to act as linguistic shorthand. These can be new terms and phrases created specifically for the TOM, or they can be existing words and phrases adapted for the TOM. And such jargon serves a valuable purpose: if you want to talk to a fellow developer about whether a given object class tree leans towards interface inheritance rather than implementation inheritance, it’s useful not to have to define and explain all those terms each time.

However, jargon can easily turn into buzzwords. For example, someone could claim a given project is object-oriented; after all, something called an “object” is involved, so it must be object-oriented, right? Well, no. Just because someone (for instance) talks about object-oriented technology or even starts using words such as software components, reuse, polymorphism, refactoring, enterprise architecture and dynamic binding, it doesn’t mean they know what they’re talking about. They may not even know that they don’t know what they’re talking about, because they may not fully understand all the implications and requirements of that concept. It’s like the old joke: What’s the difference between an IT salesman and a used car salesman? The used car salesman knows how to drive (i.e., use his own product) and knows when he’s lying.

Symptoms

Constant and unthinking repetition of key words, which are used almost as a mantra to chant problems and difficulties away or to ensure good fortune and product success. Repeated assurances that there will be no extra costs, that you’ll get the TOM benefits “for free.”

Consequences

The most benign consequence — if “benign” is the correct term — is that you don’t get the promised benefits but the project gets done anyway. The worst consequence is that the project itself turns out to be infeasible — or, at least, very late and over budget– because those concepts turned out to be critical to project completion or success, even if they weren’t understood.

Detection

This pitfall can be difficult to detect for two reasons. First, it requires probing questions and review by someone who really does understand the TOM’s concepts and who has experience implementing them. The issue then becomes, whom do you trust? If you’re technical, you may think that your fellow engineer actually knows what she is talking about; furthermore, in the interests of team unity, you may be unwilling to question or challenge her. If you’re not technical, then you’re at an even greater disadvantage.

The second problem with detection is that, based on your own experience and technical level, it can be hard to distinguish this situation from the situation in which the person actually does know what she’s talking about.

Extraction

First, be honest and admit that there may be a problem. Get someone from outside the group — preferably someone from outside the company, but at least someone with no ties to group members — to come in and do a project review with the intention of examining the quality of the TOM concepts applied to the project. This person must have a sound understanding of the TOM in question, must know all the tough questions to ask, and must be willing and able to ask them. If you can’t get this done officially (for example, you’re an engineer, and your manager doesn’t want to face these questions), then see whether you can do the check unofficially.

If the problem turns out to be real, then you get to make a career decision: Raise the red flag, call things to a halt, or push ahead anyway.

Prevention

First, educate yourself and other team members. Read articles, websites, and books on the TOM. Attend seminars, if possible. Pass around books, articles, web links and seminar materials. Ask lots of questions, but be prepared to get pushback from individuals who are insecure in their own understanding.

Second, get or hire experience. Try one or two or three small-scale TOM-based projects before tackling a large one. Make at least one of those small-scale projects a prototype for your larger, more important project. Hire developers and managers with a proven track record in the TOM.

Contributor/References

Webster; adapted 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.