Some of the words I dread most in a meeting are: "What if ?" They're fine in the present tense of "What if a user tries this option?" or "What if the database read fails mid flight?", but as soon as the future tense is introduced I begin to worry. "What if the database and middleware changes?" or "What if sometime soon we don't just have to run on PCs but need to work on mobile phones?" There is also the future future tense such as "What happens to the UI if the operating system is ported to run on a wrist watch?" or "What if one day the company merges with another whose corporate standard is MAC and SNA?"

My first IT job was building computer systems for Insurance Syndicates to allow them to manage their policies, collect premiums, and pay out claims to the less fortunate of their clients. It's a difficult business arena, with companies either losing or making a ton of money; our job was to provide them with systems to help stack the odds in favor of the latter. As well as supporting an existing 10-year-old application, we were all busy working on the next one, which was an entire rewrite. It suffered from all of the second-system syndrome features that usually plague such projects, where every feature, bell, and whistle that didn't get put into the first one gets incorporated.

What ultimately plagued and doomed the project was the "what if" over-engineering that went into its design. The business analysts tried to soothsay every possible scenario that would occur in the future, including some that would have required wholesale deregulation of the market and acts of parliament before they could ever become reality. Such schemes were happily programmed in with the foresight that if they were needed, a soft-coded switch could be thrown and the application would adapt itself in flight. Database rows had unused columns that, at the throw of a switch, would be activated onto users' screens and reports. The reality, of course, was that none of the scenarios that the analysts predicted ever occurred, and the amount of additional soft coding and layers of abstraction meant the software was slow and bulky. We lost almost all our market share to the competition, which just built lean, focused software. Even when big changes did occur to the market, such as the introduction of the Euro as an accounting currency, this required huge changes to the application because it naturally wasn't one of the future scenarios that had been predicted.

It's not just analysts who suffer from "whatifitis" syndrome. Programmers are just as guilty of using this as the excuse to over-engineer designs and code. The first OO project I worked on had to talk to a relational database back end, and we set about tackling this by creating code that could read and write our business objects. After a while it became apparent that the same logic was being used over and over, so this was refactored into a common set of class libraries, and behold a persistence mapping framework was born. Management got very excited about this, believing we'd built some kind of IT Rosetta stone, and talked to our software vendor who brought in some consultants. They raised the possibility that the database tables beneath our objects might change shape and we had to code for that possibility, as well as the possibility that our company might merge with another with a totally different database vendor and schema, and we should cater for that. There was a lot of buzz at the time about OO databases that just stored objects right onto disk without messy rows and tables, so to be ahead of the game our persistence layer catered to this. More and more layers of indirection were built into the code that now sat between the top-level objects and the database reads and writes. This, by now, had become soft coded to look up in dictionaries and maps to figure out what it was actually supposed to be doing at each decision point. This was a cool idea that would allow a system administrator to merely tweak the soft-coded rules and introduce wholesale change to how and where the beautiful and pure OO system would get and put its data. The system never actually shipped, because after having spent about three years building it, when the company did actually merge with another they decided it was silly to spend so much on our project; they would rather spend time patching the existing system to deal with the challenges resulting from the merger.

I'm fortunate enough now to work for a major IT vendor, yet during a recent presentation was given a reminder that "whatifitis" is still alive and well. This occurred while showing a customer a product that lets them write their code once and have it run on several different clients: green screen, Java Swing, and HTML. The business scenario is for someone who has users of all three interfaces, and while the Web or Java interface we generate isn't going to win usability awards against bespoke AJAX or Swing code, it's a good solution for companies who have hundred of screens and just don't want the hassle of many expensive bespoke interfaces. Halfway through the demo, one of the customer's architects asked, "What about the X-Box?" He'd read an article that said how games consoles were the user interface of the future and wanted to know on which release were we going to support this feature. Meeting customers is always odd because I usually only get to be in a room full of managers and their high-level architects, rather than their coders who actually get the work done. Instead of replying, "What if you stopped worrying about the future and, instead of reading airport newsstand IT magazines full of FUD, you spent some time with your users, solving their day-to-day business problems"; I gave a wishy-washy answer that didn't break my company's business conduct guidelines. Pity, what if...?