Software is created by programmers who write code, testers who try and break the code before users do, and analysts who are incapable of either task. Analysts know this and like a congressman's PR agent on their lunch break, they must constantly adapt to find new ways to remain on the payroll. The answer in IT is no different than any similar dilemma in which a person finds himself: bluff, fraud, and deceit.

For inspiration, the analyst thinks back to those days at school when he or she sat in science classes and gazed at complicated diagrams being drawn by the teacher. The kids who understood what the teacher was saying went on to become proper engineers, while the befuddled analysts instead picked up the subliminal message "complicated diagrams = good". The syllogism was clear ­ if they too could create presentations that others couldn't understand perhaps one day they could assume the same authoritative role over the audience that the science teacher enjoyed.

Acting on this childhood experience, the analyst buys books about analysis patterns and sets about to confuse and overwhelm all around him. Expensive tools are bought that don't create any code or contribute to the finished software product, but nevertheless print out reams of paper and create meaningless diagrams. Other analysts and managers nervously guffaw compliments like the emperor's subjects in the Hans Christian Andersen fable. Data modeling becomes trendy, methodologists and process reengineers are hired, while authors of expensive and pathetic hardback books dazzle gullible conference attendees who are mesmerized by presentation foils like first year music students at a John Cage concert.

None of this, however, helps users get their software any sooner. It does have a noticeable advantage over coding, because analysis occurs at the start of a project where time and money are plentiful and the enthusiasm of senior management and users still exists. Just when coding is about to begin, the whole methodology landscape may change, and the same person who one day drew multidimensional Shlaer-Mellor data universes, overnight becomes an expert at the new techniques and wastes valuable project dollars and time convincing senior management that arguments about OO notation and design patterns are now the key to project success. A professional software analyst is a master of trend moulting, chasing bandwagons faster than a Republican party candidate.

Fortunately, it finally looked like analysts were going to be run out of town when grass root programmers gained popular acceptance for Extreme Programming (XP). This put the power back into the hands of the coders and testers who now deal directly with users, create the simplest code possible to get the job done, and do it lots of times.

XP gave me great hope that the overthrown analysts would become the Troy McClures of software development, with perhaps a few survivors becoming electric tongue scraper salesmen on late night infomercials. With this in mind, I recently attended a presentation by a famous analyst "who shall not be named" who began by saying that in the past 10 years, misguided analogies between civil engineering and software had created the mess we had all lived through. Waiting for him to admit he played more than his fair share in the whole charade, I instead had to redefine my definition of irony when he then espoused his own particular variant of XP, tried to sell his recently published book, and attempted to convince us that you had to employ his consulting skills to make sure the methodology was being followed correctly.