Pitfall: Picking the wrong horse

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

Categories: political

Face it: technology adoption is a gamble, and one often made at gunpoint. External market forces lead internal political forces to demand advances — often unrealistic ones — in information technology. Those who adopt too soon come to understand the cliché “bleeding edge”. Those who adopt too late lose opportunities and possibly market share. And so you find yourself looking a dozen new technologies and trying to decide which to adopt, knowing that only two or three are likely to succeed: that is, deliver what you need and grow with your ever-increasing demands. A winner is always easier to pick in retrospect, but you seldom have that luxury. Instead, you need to decide between adopting a “safe” technology — which may not, in the end, really meet your needs — or leading out with a newer technology and thus run the risk of finding yourself in a dead end with a non-standard or even unsupported solution or approach.

But that’s why they pay you the big bucks, right?

Just as a personal note, I spent five years (1990-95) and $7 million in venture capital as part of a software start-up that developed and shipped a design-oriented desktop publishing system for . . . the NeXTstep operating system. As I tell people, it seemed like a good idea at the time. It was a great operating system (still is — go look at Mac OS X) and certainly better than anything else out in 1990. And we were in good company at the time, with firms such as WordPerfect, Ashton-Tate, and Adobe all developing for NeXTstep as well.

But it was the wrong horse.

Symptoms

Peers and managers above you start questioning your choice of technologies. The number of other organizations adopting the technology in question doesn’t seem to be growing much, or is even shrinking. Developers experienced with the technology are hard to find.

Consequences

Your system and/or development effort struggles due to the lack of developers and third-party tools for the technologies in question. If you’re developing a commercial product, you may find a very limited market, assuming you find one at all. If you’re developing an in-house system, you may end up deploying it, but the system may be difficult to maintain and keep in production for its original hoped-for lifetime. And if you were the champion for adopting that particular technology, you may find yourself losing influence, missing out on promotions, and possibly even out of a job.

Detection

Track down and talk frequently with other firms adopting the same technology. Fact-check, as best you can, claims by the technology’s vendor regarding adoption and market share. Pay particular attention to the products or systems based on this technology that are actually deployed into real-world use.

Extraction

If you think you’ve picked the wrong horse, then start to find the right one, quickly. Figure out what it’s going to take to move over to the better (or best) technology. Work up a careful transition plan — as accurate and conservative as you can make it — and then figure out what it’s going to take to sell this to upper management. There may be no good or easy paths at this point.

Note that there are cases where you may well be best off staying on the technology you originally picked, particularly if this is an in-house system. That is, it may be more cost effective to push into production, then plan for an earlier-than-expected end-of-life for that system, rather than try to switch horses in mid-race.

Prevention

This is hard precisely for the reasons stated above: in many cases, you just don’t know what will succeed and what won’t. If you’re talking about a major decision — such was what operating system to develop for and deploy on — your choices may be limited by other factors. In general, though, you want to avoid the leading/bleeding edges — never count on version 1.0 (or even 1.x) of anything. You want to choose technologies that have been out in the marketplace long enough to have the flaws exposed and — one hopes — the biggest problems addressed.

References

[Professional observation]

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.