Pitfall: Betting the company on a given technology or methodology

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

CATEGORIES: political

Imagine the following scene. Your company’s executive staff gathers for a presentation on a new technology or methodology that will revolutionize information productivity. After a presentation citing the ongoing problems of information management, enterprise computing, and competitive response, you are presented with the solution that will boost the company’s bottom line and guarantee its future: structured development using the C programming language!

But wait! you say. Structured development has been around for a long time, as has C. Lots of folks use structured development and C with mixed results; indeed, many don’t use it well. Lots of companies have gone out of business while relying upon structured development and C. How are structured development and C going to guarantee our future?

Good question. And yet, structured development and its associated methodologies — not to mention the C programming language and its versions — are likely more mature, established, and well understood in real-world applications than are any of the later technologies or methodologies (”TOMs”) that you may want to adopt. For that matter, the number of competent, practicing engineers who are expert at structured development and/or C is likely greater than the number of competent, practicing engineers who are expert at the particular TOM in question. If a company can’t succeed using structured development and C, why does it think it can succeed using a given TOM?

You may think that I’m being reactionary or that I don’t understand all the benefits that more modern TOMs have over structured development and/or C. If so, you miss the point: It is not technique (using Jacques Ellul‘s term) in and of itself that will benefit the company, but rather its intelligent and purposeful application by people who know what they’re doing and why. To think that adoption of a given TOM (or even a collections of TOMs) will suddenly make everything better is irrational to the point of superstition.

Symptoms

Unrealistic expectations on the part of upper management. Marketers overpromising delivery times and feature lists. Technical managers who see the TOM as a silver bullet. Developers neglecting solid software engineering practices, because the TOM “doesn’t require them”.

Consequences

At best, you go through a wrenching reeducation and attitude adjustment. At worst, you lose the bet — and the company.

Detection

Take the company’s current business plan, mission statement, and product plans, and eliminate all references to and consideration of the TOM(s) in question. Do these documents still make sense?

Extraction

Point out, repeatedly, that it doesn’t matter what technology you use if the products aren’t worthwhile and if the company can’t get a return on investment. Enumerate the factors required for success independent of the TOM(s) in question. Look at all that you can do to maximize those factors. Then — and only then — look at how the TOM(s) in question can aid and support those efforts.

Prevention

Bet the company on your people, not on some technology or methodology. Isn’t that what politics is all about?

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.