00 Practical Programmer lo 7/10/99 12:45 PM Page 17

Practical Programmer

Robert L. Glass

Buzzwordism and the Epic

$150 Million Software Debacle
“It was a classic example of two
common human behaviors; a will-
ingness to abdicate common sense
when presented with a sure thing,
and a failure to respond when
faced with overwhelming evidence
to the contrary.”
—Chris Craddock, in “The
REAL Inside Story of Westpac’s
CS90,” the Software Practitioner,
March 1999.
Australia, where management
wanted to leap forward from a
collection of tired legacy systems
to a new concept in banking
application software development.
It was an ambitious plan, and, in
the final analysis, a spectacularly
failed one. Westpac burned at
least $150 million in the effort,
and ended up with nothing to
show for it except some worthless
code and some
approach fail?”
When Westpac began planning
the new system to replace the old,
according to Chris Craddock,
who is my new source of insight
on what happened on that ill-
fated project and who was a mem-
ber of the project team, its
traditional information systems
people were tied up doing tradi-
tional IS things, so “academics
were hired to take on more free-
thinking projects.” And here

T
here’s a communication is the nub of why this
chasm between the com- story becomes a
puting world of academe
and the computing world of
industry. I’ve said that before in
this column (June 1997); I
bring it up again because
I have a new/old story
that illustrates the
kind of catastrophe
this chasm can cause.
The story is old
because it happened
back at the last turn of a
decade, as the 1980s slid
into the 1990s (in how many
fields besides computing is a 10-
year-old story out of date?). But tired and frustrated programmers. classic “communication chasm”
it’s also a new story, because I’ve “That’s not an unusual story,” outcome. “The new folks were
just received some fresh insight you may be saying to yourself. interested in data modeling, artifi-
about what happened. And, to a certain extent, it isn’t. cial intelligence, and other trendy
ROBERT NEUBECKER

This is the story of a major But what makes this an unusual subjects,” according to Craddock.
software runaway project, the story, and one worth retelling, is “None of them had ever worked
CS90 project. It happened at the the new answer to the question on [industry] software [projects],
Westpac Banking Corporation in “Why did Westpac’s software or in banking.” And yet they

COMMUNICATIONS OF THE ACM August 1999/Vol. 42, No. 8 17

00 Practical Programmer lo 7/10/99 12:45 PM
ended up with the task of rebuild-
ing all of the bank’s old software
into the spanking new CS90
system.
So far, you may be thinking to
yourself, what’s the problem?
However, Craddock’s statement to
the effect that “none of them had
ever worked on …” is a solid clue.
The problem became apparent
fairly quickly after the academics
came on board. Before long, they
had invented a whole new
approach to building banking
software. For instance, there
“The original staff of 30 grew to
more than 330 in less than four years,
eventually occupying four separate
buildings.”
would be a Product Development
Facility at which reusable business
logic components would be built,
and a System Development Facil-
ity in which application software
would be glued together from
those PDF components. There
would be a “CS90 engine” that
would do the gluing. There would
be a strong flavor of object-orien-
tation, with “supertype classifica-
tion schemes” to “formalize” the
components. There would be
heavy use of inheritance “to tie
together the high-level supertypes
through requirements to the
lower-level design and implemen-
tation objects.” There would be a
“state machine model in which
operations can be viewed as func-
tions applied to a defined set of
data items.” There would be
18 August 1999/Vol. 42, No. 8 COMMUNICATIONS OF THE ACM
Page 18
“knowledge engineering” to “con-
figure the necessary application
systems from the components.”
These quotes were from a slick,
elegantly produced brochure pre-
pared by Westpac as the project
started. They formed a glut of
creeping buzzwordism, a clear
warning to anyone who under-
stood application software devel-
opment that strange things were
afoot. When I received and read
the brochure in the early 1990s, I
was so concerned that I wrote to
Westpac, asking for clarification
regarding whether the brochure
really meant what it said, and how
it was all working out. No one at
Westpac ever responded to me. (It
turns out, by the time I saw the
brochure, that CS90 was in the
process of coming unglued).
Now let’s return to the theme
of the communication chasm. I
can imagine some of my academic
colleagues, after reading the last
paragraph, saying to themselves,
“What’s wrong with all of that?” I
can imagine some of my industry
colleagues, after reading the last
paragraph, saying to themselves,
“Now there’s a recipe for disaster.”
If those widely differing reactions
don’t define a communication
chasm, I don’t know what does.
So what happened to CS90
along the way? Craddock gives us
some fascinating insights.
Early on, the IS people on the
CS90 project were given in-house
lectures on some of the new con-
cepts to be used in the construc-
tion of the system. At one of those
lectures, Craddock says, “we were
asked to believe at least six impos-
sible things before lunch on the
first day. …We were in Wonder-
land,” he said, and “the Mad Hat-
ter … was firmly in control.” The
project, he says, then went on to
what Craddock refers to as “the
CS90 Reality Distortion Field,” in
which “technical problems were
ignored and … there was an illu-
sion of careful project manage-
ment where none in fact existed.”
Things rapidly went from bad to
worse. “The original staff of 30
grew to more than 330 in less
than four years, eventually occu-
pying four separate buildings.”
According to Craddock, “the
development methodology was
unworkable” and the “major
assumptions all came unglued at
more or less the same time … It
was obvious,” he said, “CS90 was
going to be an epic disaster.”
As the system reached its death
throes, there were cover-ups and
outright lies. Version numbers
were assigned almost randomly to
present the appearance of progress
where little was being made (for
example, releases 2, 4.2, and 6.2
were consecutive releases). Crad-
dock scanned the programmer
libraries and found that “90% of
the ‘finished’ code simply did not
exist anywhere.” And in perhaps
the strangest irony of an already
strange story, some of the acade-
mics on the project wrote up their
approach for a well-known com-
puting journal—and proclaimed it
a success.
00 Practical Programmer lo 7/10/99 12:45 PM Page 19

Practical Programmer

Eventually, Westpac gave
up on all the buzzword-laden
approaches, and “struggled along
for another couple of years using
traditional development methods.”
But it was too late. “Westpac’s
Information Systems [organiza-
tion] was gutted in an orgy of
downsizing. The bank still needed
to replace its business applications,
but there was no one left to build
them.” This and some other major
problems going on at the same
time caused Westpac to “fall from
my practitioner friends saying.
And here we are, back again, at
that communication chasm.
The last time I broached this
subject in this column, I closed
with what I hoped were some
moderating thoughts. “I would
like to believe that this column,
which may appear to be an attack
on academe, is actually the begin-
ning of the end of such attacks …
I hope I am helping with the nec-
essary bridge building that eventu-
ally must take place” to span the
chasm. And then I closed with,
“Would you help me?”
Will you? c
Robert Glass (rglass@indiana.edu) is
the publisher of the Software Practitioner
newsletter and editor of Elsevier’s Journal of
Systems and Software.
© 1999 ACM 0002-0782/99/0800 $5.00

CALLING
first to last place among its com-
petitors in less than four years.
They had ‘bet the bank’—and lost
it all.”
Once it was obvious that things
were going awry—once the Mad ALL AUTHORS
Hatter was in control, and the
Reality Distortion Field was in
place—why didn’t someone blow
the whistle on the madness?
“Maybe they know something I
don’t,” Craddock remembers say- There are so many fascinating
ing to himself at the time. And
besides, “we were told to ‘shut up
computing stories to tell, we
and get on with it.’ Ours is not to can sure use some help.
reason why … ” The academics Please consider writing or proposing
who were in charge were extremely
convincing—after all, they had an article for Communications
sold Westpac upper management based on your own technological
on their beliefs—and it was diffi-
cult for a lowly practitioner to expertise. We can never get
believe that he or she knew more enough timely, topical articles
than those in charge did about
their area of expertise. Or, even if on new trends or latest advancements.
an underling did, to convince We encourage you to review
upper management of it.
Was it really so obvious that the our author guidelines at
collection of academic buzzwords
presented in the CS90 brochure
spelled doom for an application
software project, that it would
become a $150 million blunder? www.acm.org/cacm/Authors.html
“Of course not,” I can hear some
of my academic friends saying. “It for more information.
certainly was,” I can hear some of

COMMUNICATIONS OF THE ACM August 1999/Vol. 42, No. 8 19