| By Java News Desk |
Article Rating: |
|
| August 1, 2003 12:00 AM EDT |
Reads: |
16,695 |
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.
I often wonder whether the FBI department investigating bogus claims by
companies selling penis-enlargement pills should perhaps turn their
attention to professional software analysts. Same scam, different scenario.
Subscribe to JAVA Developer's Journal Email News Alerts
Subscribe via RSS
