Claims That It Wasn t Really Important


The original description of C3 by Kent Beck

I am involved in a GemstoneProject at ChryslerCorporation to replace their many payroll applications with a single application. The project has been going on for a couple of years . I was brought in to help with PerformanceTuning, but ended up as a sort of HeadCoach of an effort to StartFresh. [27]

differs somewhat from the following postmortem descriptions by various other XP authors who were involved in the project.

In defense of C3, Chet Hendrickson posted this to the C2Wiki (our emphasis):

GROUCHO  

None of this actually matters, because building a payroll systems [sic] was C3 s secondary goal. I don t think anyone has written about this before, mostly because it happened before RonJeffries joined the team. The team s original charter, and it was reiterated when the decision to bring in KentBeck was made, was to learn how to use object technology, to learn how to manage projects that use it and if we built a new payroll system, that would be gravy. [28]

Hendrickson also posted this to comp.software.extreme-programming in January 2002 (also see Figure 2-10):

click to expand
Figure 2-10: Building a payroll system was C3's secondary goal.

The truth is that all software projects run until they are cancelled. The successful ones deliver value before the plug is pulled. If you think 4 years is a long time for a payroll system, think about how long the Microsoft Word project has been going on. Its [sic] been about 10 years and they are not done yet! That is an awfully long time to build an [sic] text editor. [29]

And this is from Robert Martin (who wasn t on the C3 project) in the same thread:

C3 was a project that was started by the IT group as a ˜research project. They wanted to understand the benefits of using OO. So they commissioned C3 to be done in Smalltalk. Eventually IT learned what they wanted to learn. OO doesn t naturally deliver. It requires a gelled team to deliver. IT did not want to continue paying for the team since it was not their responsibility to replace the payroll system. The finance department was not interested in paying for the team either. They had a payroll system already. So, in the end, IT decided to shut down the team.

An earlier description of C3 (around 2000, after the project had been cancelled) as a research project prompted this slightly puzzled response from someone who was on the original C3 team (before the crack XP squad took over):

When did C3 become a ˜research project? When I was part of the group that got involved in delivering it in 1994 it wasn t a research project ”it was a fixed price (and fixed delivery date (in 1995 I believe)) project. Could someone more knowledgeable of the project evolutions since 1995 react to the late C3 project s characterization as ˜research ? [30]

Ron Jeffries responded as follows :

It was always a research project in that it was funded by IT rather than by the customer as are most projects there. It was a research project with the intention of delivering a product, however, and the negotiation of the transition never took place between Finance and IT. This was but one of the weird things that happened. [31]

This insightful message was posted by somebody in response to Jeffries message:

If you all had talked extensively with domain experts from Finance about payroll, it seems likely that you all would have found out that what IT had you doing was not fulfilling the real needs of Finance wrt payroll. This seems to validate RUP s approach of doing deeper and more thorough investigation of the domain and requirements before high level production coding. [32]

A good point was made by someone in the later (2002) thread:

Isn t it almost asinine to use an ˜agile methodology on a task (Payroll) which CAN be completely specced out in advance, so far in advance that 10 yr old mainframe software still fits the bill? [33]

And here s Robert Martin s carefully considered response:

No.

Problems with C3

The main problem that beset C3, of course, was that the team didn t come close to getting it done in 4 years (although some XPers have since argued ” spuriously, we feel ”that this was really a sign of its success [34] ).

start example

We discuss the problem of schedule overrun (which is a high risk in any XP project) in Chapter 11.

end example
 

C3 could be thought of as a testing ground for the XP practices. As such, it had more than its fair share of problems, many of which, now that they re better understood, could probably be dealt with in advance for new projects. Other problems, we feel, are high risk regardless of whether they are well understood or not.

Ultimately, was C3 an acceptable way of failing ? A short page on the Wiki site discusses the opposite : an unacceptable way of failing. This page suggests that the following are unacceptable ways of failing: [35]

  • Lack of good common sense

  • Lack of commitment from either management or workers

  • Lack of communication

It s worth keeping these items in mind when you read through the problems that the C3 project experienced , which we summarize in the following sections.

[27] Kent Beck posting to the C2 Wiki page Chrysler Comprehensive Compensation, http://c2.com/cgi/wiki?ChryslerComprehensiveCompensation.

[28] Chet Hendrickson posting to the C2 Wiki page Cthree Project Terminated, http://c2.com/cgi/wiki?CthreeProjectTerminated.

[29] Chet Hendrickson posting to the newsgroup comp.software.extreme-programming, subject: About C3, January 16, 2002.

[30] Charles Marcus Durrett posting to the newsgroup comp.software.extreme-programming, subject: C3 dead, July 15, 2000.

[31] Ron Jeffries posting to the newsgroup comp.software.extreme-programming, subject: C3 dead, July 18, 2000.

[32] Elliott posting to the newsgroup comp.software.extreme-programming, subject: C3 dead, July 19, 2000.

[33] Jordan Bortz posting to the newsgroup comp.software.extreme-programming, subject: C3 as XP Poster child..was Re: The case against Hype ” woops other reply was blank, January 3, 2002.

[34] See http://www.c2.com/cgi/wiki?AnAcceptableWayOfFailing.

[35] See http://www.c2.com/cgi/wiki?AnUnacceptableWayOfFailing .




Extreme Programming Refactored
Extreme Programming Refactored: The Case Against XP
ISBN: 1590590961
EAN: 2147483647
Year: 2003
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net