Practical Programmer: Buzzwordism and the Epic $150 Million Software Debacle

There’s a communication chasm between the computing 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 it’s also a new story, because I’ve just received some fresh insight about what happened.

This is the story of a major software runaway project, the CS90 project. It happened at the Westpac Banking Corporation in 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 tired and frustrated programmers.

"That’s not an unusual story," you may be saying to yourself. And, to a certain extent, it isn’t. But what makes this an unusual story, and one worth retelling, is the new answer to the question "Why did Westpac’s software 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 member of the project team, its traditional information systems people were tied up doing traditional IS things, so "academics were hired to take on more free-thinking projects." And here is the nub of why this story becomes a classic "communication chasm" outcome. "The new folks were interested in data modeling, artificial intelligence, and other trendy subjects," according to Craddock. "None of them had ever worked on [industry] software [projects], or in banking." And yet they ended up with the task of rebuilding 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 would be a Product Development Facility at which reusable business logic components would be built, and a System Development Facility 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-orientation, with "supertype classification 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 implementation objects." There would be a "state machine model in which operations can be viewed as functions applied to a defined set of data items." There would be "knowledge engineering" to "configure the necessary application systems from the components." These quotes were from a slick, elegantly produced brochure prepared by Westpac as the project started. They formed a glut of creeping buzzwordism, a clear warning to anyone who understood application software development 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).

"The original staff of 30 grew to more than 330 in less than four years, eventually occupying four separate buildings."

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 concepts to be used in the construction of the system. At one of those lectures, Craddock says, "we were asked to believe at least six impossible things before lunch on the first day. …We were in Wonderland," he said, and "the Mad Hatter … 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 illusion of careful project management 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 occupying 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). Craddock 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 academics on the project wrote up their approach for a well-known computing journal—and proclaimed it a success.

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 [organization] 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 first to last place among its competitors 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 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 saying to himself at the time. And besides, "we were told to ‘shut up and get on with it.’ Ours is not to reason why … " The academics who were in charge were extremely convincing—after all, they had sold Westpac upper management on their beliefs—and it was difficult for a lowly practitioner to believe that he or she knew more than those in charge did about their area of expertise. Or, even if an underling did, to convince upper management of it.

Was it really so obvious that the collection of academic buzzwords presented in the CS90 brochure spelled doom for an application software project, that it would become a $150 million blunder? "Of course not," I can hear some of my academic friends saying. "It certainly was," I can hear some of 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 beginning of the end of such attacks … I hope I am helping with the necessary bridge building that eventually must take place" to span the chasm. And then I closed with, "Would you help me?"

Will you?

Back to Top