[From Pitfalls of Modern Software Engineering by Bruce F. Webster (forthcoming)]
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.
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”.
At best, you go through a wrenching reeducation and attitude adjustment. At worst, you lose the bet — and the company.
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?
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.
Bet the company on your people, not on some technology or methodology. Isn’t that what politics is all about?
Webster, from Pitfalls of Object-Oriented Development (1995).