Alice in Use Case Land
Methodologist's deadpan but biting allegory entertains.

Doug Rosenberg, president of Iconix and author of Use Case-Driven Object Modeling with UML (Addison-Wesley, 1999), used his Wednesday-morning soapbox at UML World 2001 on June 13, 2001 to deliver his version of Lewis Carroll's Alice in Wonderland—rewritten to skewer the Extreme Programming movement. Rosenberg's keynote slides borrowed John Tenniel's famous engravings from the first edition of Carroll's book (published in 1865), interspersed with screenshots of postings from Web newsgroups that painted an unflattering portrait of the Chrysler C3 project run by XP's most prominent voice, Kent Beck. One screenshot contained a second- or third-hand quote, ostensibly from a Chrysler executive, stating that the company experimented with Extreme Programming "once and only once." A posting from Beck himself read " … the fundamental problem was …[that] the customer feeding stories to the team didn't care about the same things as the managers evaluating the team's performance … The new customers wanted tweaks to the existing system more than they wanted to turn off the next mainframe payroll system. IT management wanted to turn off the next mainframe payroll system."

Rosenberg's keynote was divided in three parts: First, Alice encounters analysis paralysis; next, she is urged to "jump right into code" without requirements; finally, she discovers the path of moderation in the form of the four diagrams Rosenberg proposes in Use Case-Driven Modeling with UML. In part two, Alice is approached by a group of soldiers who resemble index cards—the primary planning tool used in XP to write down pieces of functionality in the form of customer stories. "Then a gust of wind blew," Rosenberg read, "refactoring the entire stack of cards." Alice is prosecuted by the Queen of Hearts for Big Design Up Front and sentenced as the jury chants "Off with her head, CMM's dead." Part three describes Rosenberg's process, including the forgotten robustness diagram, a relic from Ivar Jacobson's Objectory Method.

Though there were laughs during the talk, the audience was generally quiet, and there were no questions when Rosenberg finished. "I'm a bit disappointed by the reaction," he said quietly afterward, closing his laptop. "There's a lot of talk going on in the newsgroups and the industry about practices that I think sound a lot like things we've heard before, and I'm not afraid to speak my mind." He didn't have long to worry, however. As he gathered his equipment, a crowd of those who shared Rosenberg's skepticism had formed, and several called out their congratulations on an enjoyable, if unusual, talk.

What's Up With XP and Use Cases?
The rift widens between those who love code and those devoted to UML.

Continuing the week's Extreme Programming emphasis, the panel discussion on incorporating the most popular requirements-gathering practice—writing use cases—within so-called "agile methods" may have widened the rift between those who love reading and writing clear, elegant source code and those who prefer to model and design their systems first—either extensively or just barely—using UML. The panel members, Software Development Senior Contributing Editor Scott Ambler, Iconix President Doug Rosenberg, ThoughtWorks Chief Scientist Martin Fowler, Object Mentor Consultant Robert "Uncle Bob" Martin, and panel moderator, former Software Development Technical Editor Roger Smith, spent an hour wrangling over the model-versus-code conundrum. By the end, more than a few audience members were frustrated, saying that the advice to seek moderation was obvious and that the experts had indulged too heavily in posturing for sensational effect.

Initially sticking with the assigned topic, Fowler recommended Alistair Cockburn's book, Writing Effective Use Cases (Addison-Wesley, 2000) as the best on the subject, and endorsed use cases as complimentary to XP customer stories. "As Alistair describes them, they're very narrative, very light, no more than a few pages long and very much led by the customer."

"These panels are going to be pretty boring if we stay reasonable," Martin interjected. "It's not about not modeling or not documenting. Do it if you must, but know why you're modeling and have a goal for that model." Ideally, said Martin, the overview of the system should exist in the modelers' heads rather than on paper, but they should be able to quickly scratch it onto a whiteboard if someone asks for it.

"I use Rational Rose and Object Team," an audience member proclaimed, jumping into the fray. "And I model for one reason: because I want to create the skeleton for the code. I can lay out all my classes and objects and then generate code." This motivation didn't move the panelists, however.

"I'm not a big fan of CASE tools or diagramming tools," said Martin. "I don't like the code they generate. It puts a step between me and the code; I don't want to have to draw the diagram first." Responding to Ivar Jacobson's predictions made in a keynote here earlier in the week, Martin said "I don't believe UML will be the next programming language, and if it is, I don't think it will be a significant language, and I don't think laymen will program. I don't advise my clients to buy tools. If they've just made a big capital outlay for Rational Rose, I commiserate with them and then I help them to not use the tool."

Rosenberg disdained the idea too, but from a different angle: "If you're modeling to generate code, you're modeling for the wrong reason. It's reasonable to generate headers and overall structure, but I don't think the purpose of UML is coding. You need it for when the project is so big that you can't have everyone in the same room. The code that you get out of models, if any, is just a nice side effect."

The Horse's Mouth
Kent Beck: Eschew heavy planning and live in the moment.

"People do report that XP is exhausting at first—especially people who are used to being interrupted every five minutes," said Kent Beck, author of Extreme Programming Explained: Embrace Change (Addision-Wesley, 1999).

According to Extreme Programming (XP) guru Kent Beck, software is only now beginning to shake free of the "scientific" management concepts introduced in the early 20th century by Frederick Taylor, the first industrial engineer. Without additional capital expenditure, Taylor could double or triple a factory's output. Time studies, separate planning departments, task assignments, quality control and differential pay rates are familiar concepts, but Taylor "had a little problem with retention," said Beck in his UML World keynote on Tuesday, June 12, 2001 in New York City. Things have changed since then, however: "Today, instead of the differential rate, developers have stock options."

In the 1950s, W. Edwards Deming, the father of Total Quality Management, took the first big step away from Taylorism, explained Beck. Indeed, modern manufacturing looks very different from its Victorian origins: Workers follow a product through the plant, keep their own statistics, design and improve their own process, and have more egalitarian reporting relationships. However, the software world, Beck claims, is still clinging to an industrial manufacturing metaphor.

"There's no emphasis on maintenance. We talk about 'making' and 'shipping' products. I call this the 'spec-and-disappoint cycle.'"

But a conflict is erupting between those who emphasize a formal requirements-gathering, modeling and design process and those who espouse so-called "customer stories" dashed onto index cards. Beck considers the latter practice crucial in helping developers estimate the duration of a given requirement's development based on an ever-more-precise sense of the team's velocity in testing and building the software's frequent releases. Business people aren't cut out of the process, he said. Rather, they set scope, priority and dates.