Often in software I find myself preaching restraint to those who wish to move platforms for no apparent reason than to keep up with the IT fashion industry; however, even harder than the silver-bullet chasers is dealing with organizations where change is required, not only in a company's software stack, but throughout their entire IT department.

Recently I was involved in a customer project where the client had managed to bravely remain on a 30-year-old computing platform, while the IT fads of the '80s and '90s passed them by and were now embracing the new millennium by moving to a client/server architecture.

The first red flag with the project was that the client created a huge working group to size and spec up the new system, initially breaking off into different teams to assess various pieces of the problem. Much time was spent arguing about which technology to use, after which the IT manager, after a quick glance along his local bookstore shelf, unanimously chose for us and additionally decided that we should all embark on use case analysis.

I'm not against use cases per se; however, I like to keep them in their place as no more than an adjective to the verb "to analyze," the output of which is a set of functional requirements against which user scenarios can be tested.

The next two weeks were spent sitting in meetings with people who, clutching Use Case for Dummies, became alarmingly obsessed with whether a wireless connection was an actor or a role, or whether opening a door was a task or a scenario. The assembled architects lovingly raked up irrelevant anecdotes from their past, created fiefdoms and cliques, and meetings were dominated by aging personalities who seemingly loved nothing more than to hear the sound of their own voice while they argued irrelevant minutiae. The sane among us tried to re-orient the project toward a more agile methodology by focusing on a few simple scenarios that, through test-driven development, would be built and iterated over n times where the larger n becomes the more finessed the eventual deliverable turns out. Such heresy, to try to build the system without having formal specification design documents signed off in triplicate was shouted down by prima donnas who enjoyed warming their vocal cords all the more when senior management were present as they preached doom and gloom with stories of punched card stacks becoming dangerously mixed up on their way to the machine room.

As the weeks drew on I began to pity the IT manager who eventually fell back on the only rock he understood - a good old-fashioned waterfall design. He instructed us all to create 50 or so documents that would be sized, then summarized in a gospel-like spreadsheet, before being signed off by everyone present to create a project plan for presentation to the business units. By now, the senior managers, having spent a huge fortune and sizeable elapsed time on the redesign, concluded that their IT department was completely unable to get the job done and outsourced the project to a far flung ex-colony. I later learned from a colleague that they too failed to deliver anything of substance and the system rewrite was abandoned.

To do change well requires not only switching the technology platform, but altering how your software is designed, how it is built, how it is tested, and how it is delivered. There is little point in applying the design principles of yesteryear to implement systems in today's world where compilation is all but instant, unit tests are built into the development environment, and continuous feedback is how systems are refined. The end result can be perpetual meetings with bellicose and obstructive project personnel whose ulterior motive perhaps lies more in keeping the old, undocumented, and arcane systems alive where their inflated expertise benefits most, rather than embracing and adopting change.