The XP Project Life Cycle (As Illustrated by the Activities at C3)

The project life cycle in Figure 2-1 is our interpretation of the events that took place during and immediately after the C3 project. We ve based this diagram on information that is publicly available on the Portland Patterns Repository Wiki site (the C2 Wiki site at http://www.c2.com/cgi/wiki ), magazine and Web site articles including interviews with the XP authors, and various Internet discussion groups (including comp.software.extreme-programming) where the people involved in the project have posted copious messages.

Figure 2-1. Activities during and after C3

In this section, we trace the C3 project life cycle from its beginnings to its controversial cataclysmic cancellation ^[2] in February 2000, using the activity diagram in Figure 2-1 as a guide. We tell the story here using mostly screen shots, quotes, and song lyrics, and then we provide the commentary and analysis afterward. Think of this as a sort of simulated multimedia story trail. Everybody sing along now. . . .

We All Met on a Project Called C3

(Sing to the tune of Yellow Submarine by The Beatles)

On the Project called C threeeeeee
We told Chrysler
That change was free
Cause we could code so rapidly
And refactor endlessly

We all met on a project called C3 . . .

Hype and Fanfare

XP is announced to the world with a flourish, with grandiose claims such as The Best Team in the World, as we see in Figure 2-2.

Figure 2-2. We're the King of the World! ^[3]

C3 began in January 1995 as a fixed-price contract. The majority of the project-was finished by early 1996, but it consisted mostly of a lot of GUI screens and some functions that were calculating peoples taxes wrongly. In March 1996, the C3 project was floundering. So Chrysler brought in Kent Beck, who in turn brought in Ron Jeffries, who in turn brought in his crack team of XPers (except then, of course, they weren t known as XPers ).

Beck s plan was to courageously throw everything away and start again.

WhenYouTalk theTalkYou KnowtheTalk ThatYouTalk Is Really BigTalk

(Sing to the tune of Downtown by Petula Clark)

When you talk the talk
You know the talk that you talk is really
Big talk
Big talk

As with many doomed software projects, C3 (having been relaunched with its new Extremo power team) started out with high hopes and enthusiasm . And they were courageously Doin the Simplest Thing That Could Possibly Work !

Doin the Simplest Thing That Could Possibly Work

The team was busy shaping the XP practices and doing the simplest thing possible to get today s piece of work done (see Figure 2-3).

Figure 2-3. Do not build generality into the system in expectation of future requirements.

This description is from an article by Chet Hendrickson:

Fear is the Mind Killer

The lack of courage ”what I like to call ˜fear ”is self perpetuating and can most often be traced to an initial lack of one or more of the other three values [communication, feedback, and simplicity]. A group of progammers [sic] who fear doing the simplest thing that could possibly work because they do not have adequate acceptance testing (a lack of feedback) may later lack the courage to optimize performance due to the systems complexity. Fear will prevent you from doing the right thing, it reduces your degrees of freedom and will eventually drag your project to a halt. This is the antithesis of Extreme Programming. ^[4]

Generate a Quick Illusion of Success

About halfway through the ill-fated project (with another 2 years to go), the article shown in Figure 2-4 appeared in Distributed Computing magazine. The following is excerpted from the article:

We have been paying a pilot group since August 1998 and will roll out the rest before the Y2K code freeze in November 1999. ^[5]

Figure 2-4. Legitimacy is achieved for the Extremos by citing success on the C3 project. ^[6]

In 1997, Ron Jeffries (C3 s XP coach and later coauthor of Extreme Programming Installed ) posted this message regarding the suitability of Smalltalk (which some would argue was the first useful object-oriented language) for a payroll system:

HYPE!  

I d never have said it, but it turns out payroll is so complicated that it is very interesting finding the inner simplicities that make it possible to write a program that works. Objects are perfect for it. Smalltalk is perfect for it. That s just part of why we call C3 Payroll the best project in the world. ^[7]

During and shortly after C3, a blaze of publicity surrounded the project s purported success, bouncing XP onto the software engineering stage. Here are some examples:

The methodology was invented in 1996, when automaker Chrysler called upon Kent Beck, a software developer, to save a project known as Chrysler Comprehensive Compensation, or C3. Kurt Beck [sic] developed the method and succeeded with the project at Chrysler. The C3 system now provides monthly payroll information for Chrysler employees . ^[8]

We have focused on communication here, but many Extreme Programming practices have contributed to C3 s success: . . . ^[9]

In retrospect it would appear that the claims of success were somewhat premature. Note that, although Ron Jeffries later claimed that the project wasn t on an imagined schedule, ^[10] the early hype surrounding the project would seem to indicate otherwise :

By the end of October, the salary system s 16,000 employees will be paid by the C3 system. They will be joining the 10,000 executive system employees C3 has been paying since May of 1997. It is expected that the remaining 60,000 employees will move to C3 in mid-1999. ^[11]

They never made it. Why not? We think it might have been because they were refactoring endlessly.

Refactor Endlessly

Without deadlines, a clear set of implementation milestones, and a documented architecture, the result is bound to be something like this (also see Figure 2-5):

Figure 2-5. The C3 team reveled in Constant Refactoring After Programming.

GROUCHO  

About every 3 or 4 iterations we do a refactoring that causes us to toss or otherwise radically modify a group of classes. ^[12]

Is this a recipe for an overdue project? We think that events prove it to be so. From Extreme Programming Installed :

GROUCHO  

What if you don t have all the stories? Don t worry ”you don t have all the stories. Things will change and all the stories will come to you. You can substitute stories at the beginning of any iteration. Just get the programmers to estimate them, and stick them into the planning process when their cost and value dictate . Grab a few cards, write down the new stories, and act like you had them all the time. No one will ever notice. ^[13]

Although the XP practices were supposedly tailored around the needs of the C3 project, it s debatable whether a process that s optimized toward code maintenance and volatile requirements was really the best choice for replacing a legacy payroll system.

We discuss why we feel that XP is optimized toward code maintenance in Chapter 9 and in the section Release Early, Release Often in Chapter 13.

 

Was the C3 payroll really more complex than other payroll systems? C3 was being powered along by XP and a team that called itself the best software development team on the face of the earth, shouting BDUF! and YAGNI! at each other, yet after 4 years C3 was only one-third complete.

See Chapter 8 for a definition of BDUF and Chapter 12 for a definition of YAGNI.

 

One area of complexity that C3 did need to encompass was the myriad of rules and procedures from many different payroll systems within Daimler-Chrysler. Rome would not be redesigned in a day. However, this does rather imply that all the requirements, all the rules, all the procedures, were already well known in existing systems ”in other words, they were defined using the XPers favorite form of documentation: source code! (Smell the COBOL!) For them, integrating these disparate payrolls should have been a breeze . More to the point, they didn t need to use a process that places such a high emphasis on change.

A more suitable process would have been one that uses the best parts from XP ”unit tests, refactoring, pair programming (in moderation ) ”and combined these with an effective design process (the ICONIX Process springs to mind) that catches out all the misunderstandings and design oddities at an early stage (before the code has been written), and then allows the team to go full steam ahead with the testing and coding. Oh, well. They ll know better next time.

Abandon Ship!

As the months and years flew by from the salad days of 1996, the millennium and the much-dreaded Y2K deadline approached rapidly while the team continued refactoring. It became increasingly clear that the team wasn t going to make the imagined schedule.

In the latter stages of C3, Alistair Cockburn posted this message to the C2Wiki:

I consider XP a HighDisciplineMethodology, one in which the people will actually fall away from the practices if they don t have some particular mechanism in place to keep them practicing. Ron is that mechanism at the moment. Should (when) Ron leave, then unless he is replaced in his role, I quite expect to see the team not following the practices properly in less than 6 months. ^[14]

(Much) Further down the same page, after much discussion and offense-taking to Alistair s suggestion that not everyone on the C3 project was perfect, Ron Jeffries posted this message:

I m no longer on C3 full time. Alistair s six-month clock has started.

About 6 months later, perhaps by unfortunate coincidence , C3 was cancelled.

Cancellation

The Project Called C3 (Second Verse)

(Sing to the tune of Yellow Submarine by The Beatles)

Oh the project called C3
Was cancelled inexplicabl-eee
So we all Claimed victory
But at Chrysler
They didn t quite see
It was cancelled inexplicably
Inexplicably, inexplicably
It was cancelled inexplicably
Inexplicably, inexplicably

The Cutter Consortium s February 2000 newsletter included an interview with Ron Jeffries in which he was asked about the success of the C3 project:

As we talked, I asked Jeffries how success on the C3 project translated into XP use on other Chrysler IT projects. His grin told me all I needed to know. ^[15]

The author of the Cutter Consortium article evidently thought that the C3 project was a success. However, we occasionally wonder what Ron was grinning about because, that very same month, disaster struck:

As of the first of February, 2000, the C3 project has been terminated without a successful launch of the next phase. ^[16]

(The page that contains this quote then adds, But bear in mind that termination can be success. Groovy baby, yeah!)

A postmortem is given on the Cthree Project Terminated page ^[17] (see Figure 2-6).

Figure 2-6. C3 project terminated

Originally intended as a Y2K payroll replacement project, the year 2000 arrived with nary a whimper. The portents of millennium bug doom that the world had been dreading simply didn t manifest into anything more than a couple of ATM cards being chewed up and a battered 20-year-old digital watch unexpectedly seizing up somewhere in Wootton Bassett, England. Meanwhile at Chrysler, the mainframes that ran their payroll failed to keel over as anticipated. Because C3 was still not paying 76,000 out of 86,000 employees, we suspect it became expendable. The cancellation has, however, been cited as inexplicable by the Extremos. Seems pretty explicable to us. How much did C3 manage to achieve in its 4 long years? On the comp.software.extreme-programming newsgroup, Ron Jeffries wrote (on January 4, 2002):

It paid somewhere just under 10,000 [employees]. It was hoped that it would pay all Chrysler employees, somewhere around 100,000. It had demonstrated the ability to pay the next batch correctly (I forget, another 20,000 or something) and those people had essentialy [sic] the same pay rules as the biggest group. ^[18]

Claims of Victory and Success

By the time C3 was cancelled, XP was well on its way to becoming the phenomenon that it is today (for example, see Figure 2-7). Beck, Jeffries, Hendrickson, and others had book contracts in hand. Cries of YAGNI, BDUF, and oral documentation were sweeping the land. And something as trivial as the project s cancellation couldn t stand in the way.

It s Been Four Long Years

(Sing to the tune of Norwegian Wood [This Bird Has Flown] by The Beatles)

It s been four long years
And we can t get
The payroll to run

But we re not in tears
Cause we re having
Way too much fun

We like refactoring code till it smells like it should
And we re writing all kinds of books that make us look good

But it s been four long years
And the payroll
Still doesn t run
But we have no fears
Cause we ve convinced most every one

We re really agile and others are merely afraid
Our checks don t come from C3, so we still get paid!

But it s been four long years
And we can t get the payroll to run
Now we re all famous Isn t it great?

Isn t it fun?

The recently completed Chrysler Comprehensive Compensation (C3) experience exemplifies the above discussion. After 26 people failed to deliver what was considered a large system, an eight-person subset of the team restarted, using eXtreme Programming (XP), an extremely light and rigorous methodology. The eight people successfully delivered in a year what the larger team with heavier methodology had failed to deliver. Part of the success was its adherence to Principle 4. ^[19]

Figure 2-7. XP's success is ascribed to Mr. Beck s golden rules

However, the following quote from The Economist , which appeared almost a year after C3 had been cancelled , strikes us as being, well (insert tongue firmly in cheek) . . . um, slightly inaccurate:

XP was invented in 1996, when Kent Beck, a software developer, was called in by an American car maker, Chrysler, to rescue a project which had proved so frustrating that it had been scrapped. As Mr Beck worked on this benighted venture, known as Chrysler Comprehensive Compensation (C3), he formulated a set of directions for keeping code ˜elegantly written . The C3 system now provides correct monthly payroll information for more than 86,000 employees. It s [sic] success is ascribed to Mr Beck s golden rules. ^{[20 ]}

Puzzlement in the Newsgroups

After C3 s cancellation, the C3 pages on the Wiki, which had been very active, went rather quiet for a while. Then some sheepish explanations began to appear, some of which contradicted each other (our favorite came from Chet Hendrickson, claiming that C3 was just a research project ”more on this later). After that, there was noticeable confusion in various discussion groups (such as the Object Technology User Group [OTUG] and comp.software.extreme-programming) and the C2 Wiki (see Figure 2-8), because in some places XP was still being promoted on the back of C3 s alleged success.

Figure 2-8: It wasn't quite like the 90% done syndrome.

In a discussion that took place on the OTUG forum, XP author Robert C. Martin gave this explanation for the cancellation of C3:

GROUCHO  

Who knows what they are going to do? Certainly not you nor I. Who knows why they did what they did; again, certainly not you nor I. The only facts we really have in evidence are that the project was moving at a predictable rate that everyone was aware of, that it was paying 1/3 of the employees and ready to pay the next third. That it was inexplicably cancelled. ^[21]

The following quote from Alistair Cockburn could just about be attributed to his enthusiasm for XP leading him to exaggerate the success of C3 and the part that XP played in C3 s success :

Inexplicably? They start a Y2K project in 1996, and by February 2000 it s only one-third deployed. So it gets cancelled.

In the same message, Martin adds:

OK Doug, you can once again repeat the litany of: ˜In four long horrible drought-filled years XP delivered only one meager third of the required functionality, and has placed DC in the position of having to throw everything away and pay gazillions of dollars for a replacement. But it s a pretty lame argument.

Actually, that seems like a pretty concise statement of the facts. What exactly makes it lame other than the reality that it doesn t support the XPers marketing efforts?

An interesting summing up of the C3 project life cycle is given on the Wiki site (our emphasis):

Written in 2002: The original estimate done by the C3 team in March 1996 was that the project would be ready to ship in about a year. It launched in about a year . . . Subsequent launches of additional pay populations were wanted by top management within a year. The team thought that was possible, though I can t remember why. It doesn t seem that they succumbed to pressure but perhaps they did. After two? more years the next group was ready to ship in the team s opinion but something always got in the way. It wasn t quite like the 90% done syndrome, but there was always another requirement that just had to be done. Communication up and down the chain of command was broken; every manager but one on both the IT side and Finance side was replaced or moved to a new position. Finally the project was terminated. At this writing, C3 is no longer paying any employees, though it did so until the end of 2000. ^{[22 ]}

Is this a predictable outcome of scope creep due to not writing requirements down? We think so. This is exactly why we write specifications. Forty years of software engineering experience has taught us that major problems happen when you don t write the requirements down and just let a team ^[23] build what it likes. It is sheer lunacy to ignore this experience. But anyone who suggests otherwise is branded a coward in the Extremo culture. The inmates are running the asylum .

The explanation from Kent Beck is as follows :

Near as I can tell the fundamental problem was that the GoldOwner and GoalDonor weren t the same. The customer feeding stories to the team didn t care about the same things as the managers evaluating the team s performance. This is bad, and we know it s bad, but it was masked early because we happened to have a customer who was precisely aligned with the IT managers. The new customers who came on 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. Game over. Or not, we ll see . . . ^[24]

It seems pretty clear from reading this. The GoalDonor was told by the XP team that they should embrace change and that change is free. So what did they do? They told the programmers to fiddle with features. The GoldOwner wanted to still be able to pay their employees on January 2, 2000, and had started the project (in 1996!) because they were afraid the mainframes would die on January 1, 2000.

It got cancelled inexplicably in February 2000 when the mainframes didn t die as expected. Their agile techniques failed to replace a mainframe payroll system in 4 years (4 years!). How is this an increase in productivity?

When Ron Jeffries was asked this question on OTUG, he replied

GROUCHO  

XP doesn t claim ˜fabulous productivity gains. We claim to tell you where you are. Have I published something to the contrary? Let me know, I ll correct it. ^[25]

Riiiiiiiiiiight. This is from Jeffries book Extreme Programming Installed :

We give you the ability to move very rapidly, and to change your requirements any time you need to. ^[26]

Meanwhile, one is inclined to wonder what the management at Chrysler made of all this. At the time of this writing, we heard that Chet Hendrickson is involved in a new XP project in a different part of Chrysler. However, the initial reaction of the Chrysler management appears to have been far from favorable (see Figure 2-9 for an example of the discussion of C3 s termination on theWiki site).

Figure 2-9: . . . in the view of DC s management C3 was a disastrous project . . .

^[2] Of course, this is just our opinion! As we attempt to demonstrate in this chapter, the level at which a project really fails is entirely dependent on your point of view. One person s failure is another person s roaring success.

^[3] Chet Hendrickson, DaimlerChrysler: The Best Team in the World, http://www.computer.org/SEweb/Dynabook/DaimlerChryslerSdb.htm (reprinted from Computer, Vol. 32, No. 10, October 1999).

^[4] Chet Hendrickson, When is it not XP? http://www. xprogramming .com/xpmag/NotXP.htm , December 5, 2002

^[5] Chet Hendrickson, DaimlerChrysler: The Best Team in the World, op. cit.

^[6] The C3 Team, Chrysler Goes to ˜Extremes, Distributed Computing , October 1998, p. 4 (reprinted on http://www.xprogramming.com/ publications /dc9810cs.pdf ).

^[7] Ron Jeffries posting to the newsgroup comp.lang.smalltalk, subject: No One Does Payroll in Smalltalk, August 3, 1997.

^[8] Juergen Daum, How to make software developers more productive through ˜Extreme Programming, http://www.juergendaum.com/news/04_11_2001.htm, April 2001.

^[9] The C3 Team, op. cit.

^[10] Ron Jeffries posting to OTUG ( http://www.rational.com), subject: C3 Project Terminated, October 10, 2000.

^[11] The C3 Team, op. cit.

^[12] Chet Hendrickson posting to the C2 Wiki page Chrysler Comprehensive Compensation, http://c2.com/cgi/wiki?ChryslerComprehensiveCompensation.

^[13] Ron Jeffries, Ann Anderson, and Chet Hendrickson, Extreme Programming Installed (New York, NY: Addison-Wesley, 2000), p. 30.

^[14] Alistair Cockburn posting to the C2 Wiki page High Discipline Methodology, http://www.c2.com/cgi/wiki?HighDisciplineMethodology.

^[15] Jim Highsmith, Extreme Programming, http://www.cutter.com/freestuff/ead0002.pdf, p. 4. (This article originally appeared in the February 2000 edition of Cutter Consortium s e-Business Application Delivery newsletter.)

^[16] See http://c2.com/cgi/wiki?ChryslerComprehensiveCompensation .

^[17] See http://c2.com/cgi/wiki?CthreeProjectTerminated .

^[18] Ron Jeffries posting to the newsgroup comp.software.extreme-programming, subject: C3 as XP Poster child, January 4, 2002.

^[19] Alistair Cockburn, Selecting a Project s Methodology, IEEE Software ( http://www.eee.metu.edu.tr/~bilgen/Cockburn647.pdf), July/August 2000.

^{[20 ]} Extreme measures, The Economist Technology Quarterly , December 7, 2000. (Also referenced at http://www.xp.co.nz/XP_Seminar.htm.)

^[21] Robert C. Martin posting to OTUG ( http://www.rational.com), subject: The Doug and Ron Show: An analysis of the termination of C3, October 11, 2000.

^{[22 ]} See http://c2.com/cgi/wiki?ChryslerComprehensiveCompensation .

^[23] That includes the on-site customer representative ”just one of the project s many masters.

^[24] Kent Beck posting to the C2 Wiki page Cthree Project Terminated, http://c2.com/cgi/wiki?CthreeProjectTerminated .

^[25] Ron Jeffries posting to OTUG ( http://www.rational.com), subject: C3 Project Terminated, October 10, 2000.

^[26] Ron Jeffries et al., Extreme Programming Installed , op cit., p. 33.