C3 dead.

C3 dead.

Post by Daniel » Sat, 08 Jul 2000 04:00:00






>> I just noticed on Wiki an announcement that I'm suprised has not made
>> it here ( or perhaps it did and I missed it, in that case sorry). The
>> C3 project at Chrysler has been terminated. At this point, I don't
>> know any of the details.

>Projects come and projects go.  C3 is no longer under development; but the
>software is still in production cutting lots and lots of checks.

So far, all I have read is from the mouths of developers and not managers.
Predictably, they are all saying it was the fault of management...

However, it seems that the C3 project was shutdown after fulfilling 33% of
its original requirements (I'm assuming that it was meant to pay all 27K
people, and not just the 9K people it currently pays.) One has to admit
that a BigUpfrontDesign wouldn't be able to say that, it would be either
all or nothing.

It also seems that the DC management is calling the project a failure
despite the fact that it is paying 9K people. I would like to hear
management's take on why it is a "failure". (Obviously I'm not going to
hear that on Wiki or this newsgroup. :-)

Reuters says:

    DaimlerChrysler's efforts will go beyond that, attacking costs and
    wasted time within the company's design, engineering, procurement and
    supply, inventory, retail and transportation operations, Dilts said.

    ``Time is money in our business,'' he said.

Was C3 one of the things taking too much time for the money spent? Maybe
management determined that the extra "value" that the C3 project was
giving them, compared to the old system, wasn't worth the extra cost?
Maybe someone woke up and realized that the old system didn't need
replacing after all?

Questions, questions...

 
 
 

C3 dead.

Post by Univer » Sat, 08 Jul 2000 04:00:00


#However, it seems that the C3 project was shutdown after fulfilling 33% of
#its original requirements (I'm assuming that it was meant to pay all 27K
#people, and not just the 9K people it currently pays.) One has to admit
#that a BigUpfrontDesign wouldn't be able to say that, it would be either
#all or nothing.

I don't what your "BigUpFrontDesign" is, but there are many RUP like projects,
that before beginning the guts of high level production coding,  investigated
key use cases, outlined an overall architecture for achieving those use cases,
and had an iterative release schedule that replanned as necessary before each
major iteration have shown themselves able to easily handle this.

Elliott
--
   :=***=:  Objective  *  Holistic  *  Overall pre-code Modelling  :=***=:
                      Hallmarks of the best SW Engineering
   study Craftite vs. Full Blown OO:  http://www.radix.net/~universe
copyright 2000 Elliott. exclusive of others' writing. may be copied freely
                 only in comp., phil., sci. usenet & bitnet & otug.

 
 
 

C3 dead.

Post by Robert C. Marti » Sat, 08 Jul 2000 04:00:00






> >> I just noticed on Wiki an announcement that I'm suprised has not made
> >> it here ( or perhaps it did and I missed it, in that case sorry). The
> >> C3 project at Chrysler has been terminated. At this point, I don't
> >> know any of the details.

> >Projects come and projects go.  C3 is no longer under development; but
the
> >software is still in production cutting lots and lots of checks.

> So far, all I have read is from the mouths of developers and not managers.
> Predictably, they are all saying it was the fault of management...

> However, it seems that the C3 project was shutdown after fulfilling 33% of
> its original requirements (I'm assuming that it was meant to pay all 27K
> people, and not just the 9K people it currently pays.) One has to admit
> that a BigUpfrontDesign wouldn't be able to say that, it would be either
> all or nothing.

> It also seems that the DC management is calling the project a failure
> despite the fact that it is paying 9K people. I would like to hear
> management's take on why it is a "failure". (Obviously I'm not going to
> hear that on Wiki or this newsgroup. :-)

> Reuters says:

>     DaimlerChrysler's efforts will go beyond that, attacking costs and
>     wasted time within the company's design, engineering, procurement and
>     supply, inventory, retail and transportation operations, Dilts said.

>     ``Time is money in our business,'' he said.

> Was C3 one of the things taking too much time for the money spent? Maybe
> management determined that the extra "value" that the C3 project was
> giving them, compared to the old system, wasn't worth the extra cost?
> Maybe someone woke up and realized that the old system didn't need
> replacing after all?

> Questions, questions...

Ron did a talk at XP2000 about the fate of C3.  (Ron, we should do a
webinar.)  As I understand it, the fundamental issue revolved around who was
paying for the development.  IT was funding it as a research project and
wanted the (payroll dept?) to take over.  The ensuing battle lead to the
shutdown of the project before all functionality was complete.  It was the
classic dichotomy between the GOAL DONORS and the GOLD OWNERS.  (i.e. the
real customer wasn't the one paying.  The one paying was not the customer.)

(Ron, you could describe this better than I can.)

--

Robert C. Martin    | "Uncle Bob"              | Training Courses:

PO Box 85           | Tel: (800) 338-6716      | Extreme Programming.
Grayslake IL 60030  | Fax: (847) 548-6853      | http://www.objectmentor.com

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

 
 
 

C3 dead.

Post by Edward V. Berar » Sat, 08 Jul 2000 04:00:00




> However, it seems that the C3 project was shutdown after fulfilling 33% of
> its original requirements (I'm assuming that it was meant to pay all 27K
> people, and not just the 9K people it currently pays.) One has to admit
> that a BigUpfrontDesign wouldn't be able to say that, it would be either
> all or nothing.

It is bad enough that non-XP approaches have to be characterized using
a pejorative term like "BigUpfrontDesign" and all of its negative
connotations. Do you have to misrepresent literally hundreds of
software development methodologies?

The only projects that I have ever worked on, or know about, that were
"either all or nothing" shared much more in common with XP than with
more conventional approaches. The "all or nothing" aspect was not
necessarily a negative characterization. That is, the use of powerful
tools allowed for very rapid development. So rapid, in fact, that one
could afford to discard an unsatisfactory solution and quickly create
another one.

Even old-fashioned waterfall approaches allowed for "resizing" or
"changes in scope." In fact, the reviews that were conducted at the end
of each life-cycle phase, required that a "go/no-go" assessment be made
before going on to the next phase. In addition, any
recommended/required changes in project scope (or size) had to be
documented.

Are there actually people out there that believe that all changes are
forbidden in non-XP projects?

            -- Ed

--
**********************************************************************
Edward V. Berard                  | Voice: (240) 271-3777
The Object Agency, Inc.           | Fax:  

Gaithersburg, Maryland 20885-4116 | Home Page: http://www.toa.com/
U.S.A.                            |
*Consulting, Training, & Research in Web/Internet/Intranet Technology*

 
 
 

C3 dead.

Post by Daniel » Sat, 08 Jul 2000 04:00:00




>> However, it seems that the C3 project was shutdown after fulfilling 33% of
>> its original requirements (I'm assuming that it was meant to pay all 27K
>> people, and not just the 9K people it currently pays.) One has to admit
>> that a BigUpfrontDesign wouldn't be able to say that, it would be either
>> all or nothing.

>It is bad enough that non-XP approaches have to be characterized using
>a pejorative term like "BigUpfrontDesign" and all of its negative
>connotations. Do you have to misrepresent literally hundreds of
>software development methodologies?

It was not my intent to misrepresent any methodologies. It was my intent
to characterize an iterative methodology as being better at delivering
value to the customer *even if it is considered a failure*. AFAIK, over
the years, methodologies have espoused shorter and shorter iterations with
XP being the shortest so far. Maybe too short?

Quote:>Even old-fashioned waterfall approaches allowed for "resizing" or
>"changes in scope." In fact, the reviews that were conducted at the end
>of each life-cycle phase, required that a "go/no-go" assessment be made
>before going on to the next phase. In addition, any
>recommended/required changes in project scope (or size) had to be
>documented.

>Are there actually people out there that believe that all changes are
>forbidden in non-XP projects?

Forbidden? No, not forbidden. However I do believe that many projects
place barriers to change, for example the requirement that business must
get approval from development before bringing changes to the table (IE
they have to *ask* for the change.) Also, the insistence of designers to
not allow the customer to see the product in its nascent form (so that
they less time to evaluate the system.)

What we need is a methodology that explicitly states that the customer is
always right, no matter how fickle or short sighted we may think him to
be. If the customer turns out to be wrong, it's because the developer
failed to give the customer the knowledge he needed. AFAIK, XP has come
closest to this ideal.

From what little I have been able to read about the C3 project, (again it
is all from the developers prospective) the developers lost sight of *who*
the customer really was. There are still, however, many questions. For
example, I've read that the developers were being paid by IT (research?)
but producing a product for Payroll. Who exactly is calling the project a
failure, IT or Payroll?

 
 
 

C3 dead.

Post by Daniel » Sat, 08 Jul 2000 04:00:00



Quote:>Ron did a talk at XP2000 about the fate of C3.  (Ron, we should do a
>webinar.)  As I understand it, the fundamental issue revolved around who was
>paying for the development.  IT was funding it as a research project and
>wanted the (payroll dept?) to take over.  The ensuing battle lead to the
>shutdown of the project before all functionality was complete.  It was the
>classic dichotomy between the GOAL DONORS and the GOLD OWNERS.  (i.e. the
>real customer wasn't the one paying.  The one paying was not the customer.)

>(Ron, you could describe this better than I can.)

Yes Ron, please do because the above tells us nothing.

Did the so called Goal Donors and Gold Owners want different things? What
were the research departments goals? Were they met? What principals of XP
come to bare or will be developed in order to forestall this sort of
problem in other XP projects? Did the XP Developers simply forget the
Golden Rule (he who has the gold makes the rules?) It seems that Payroll
was not impressed enough with the C3 system to be willing to front the
money, was the project not producing enough return on investment? Couldn't
that be a serious flaw with XP if true? Or maybe Payroll couldn't afford
the investment no matter what the return?

 
 
 

C3 dead.

Post by Daniel » Sat, 08 Jul 2000 04:00:00




>#However, it seems that the C3 project was shutdown after fulfilling 33% of
>#its original requirements (I'm assuming that it was meant to pay all 27K
>#people, and not just the 9K people it currently pays.) One has to admit
>#that a BigUpfrontDesign wouldn't be able to say that, it would be either
>#all or nothing.

>I don't what your "BigUpFrontDesign" is, but there are many RUP like projects,
>that before beginning the guts of high level production coding,  investigated
>key use cases, outlined an overall architecture for achieving those use cases,
>and had an iterative release schedule that replanned as necessary before each
>major iteration have shown themselves able to easily handle this.

You have just done a wonderful job of describing XP in a single paragraph.
Thanks for the input.
 
 
 

C3 dead.

Post by Univer » Sat, 08 Jul 2000 04:00:00


   [elided]

#And
   if you
#agree XP is like RUP, I thought you said only XP could have done what it
#did.

Elliott
--
   :=***=:  Objective  *  Holistic  *  Overall pre-code Modelling  :=***=:
                      Hallmarks of the best SW Engineering
   study Craftite vs. Full Blown OO:  http://www.radix.net/~universe
copyright 2000 Elliott. exclusive of others' writing. may be copied freely
                 only in comp., phil., sci. usenet & bitnet & otug.

 
 
 

C3 dead.

Post by Ronald E Jeffrie » Sat, 08 Jul 2000 04:00:00





>>Ron did a talk at XP2000 about the fate of C3.  (Ron, we should do a
>>webinar.)  As I understand it, the fundamental issue revolved around who was
>>paying for the development.  IT was funding it as a research project and
>>wanted the (payroll dept?) to take over.  The ensuing battle lead to the
>>shutdown of the project before all functionality was complete.  It was the
>>classic dichotomy between the GOAL DONORS and the GOLD OWNERS.  (i.e. the
>>real customer wasn't the one paying.  The one paying was not the customer.)

>>(Ron, you could describe this better than I can.)

>Yes Ron, please do because the above tells us nothing.

I'm sorry, but I wasn't there at the end and for the same reason that
I didn't put my talk in the XP 2000 proceedings, I don't feel at
liberty to put many of my observations in print here. Catch me over a
beer sometime.

I will say that the team was still doing XP and still delivering
functionality as requested and at pretty much the same velocity. The
technical side of the project was in no way wedged. I'm sure the
situation was far more complicated than Bob described, and even far
more complicated than I described in Sardinia. The short answer is as
Bob described.

R

Ron Jeffries                    

I'd like to invite you, just for a while, to think about your work in a different way.

 
 
 

C3 dead.

Post by Edward V. Berar » Sat, 08 Jul 2000 04:00:00





> >It is bad enough that non-XP approaches have to be characterized using
> >a pejorative term like "BigUpfrontDesign" and all of its negative
> >connotations. Do you have to misrepresent literally hundreds of
> >software development methodologies?

> It was not my intent to misrepresent any methodologies. It was my intent
> to characterize an iterative methodology as being better at delivering
> value to the customer *even if it is considered a failure*. AFAIK, over
> the years, methodologies have espoused shorter and shorter iterations with
> XP being the shortest so far. Maybe too short?

Most, but not all software development methodologies are iterative.
Specifically, they allow the developers to return to any point in the
life-cycle, introduce a change, and then propagate the effects of that
change. Saying that a life-cycle approach is iterative is a fairly
non-informative.

A sequential life-cycle is one in which, once a step is completed, you
are not allowed to return to that step, or to any step previous to that
step. Such approaches are only practical for very small projects, or
projects where powerful rapid development tools are available.

A recursive life-cycle is one in which the development process can be
reapplied to the results of the development process. All recursive
life-cycle approaches are also iterative, but all iterative life-cycle
approaches are not also recursive.

In classic iterative waterfall life-cycles, recursion usually takes
place within a phase (e.g., analysis, design, or coding). Iteration
also takes place within a phase. However, iteration can also cross
phase boundaries.

One of the primary differences between classic waterfall, and most
object-oriented life-cycle approaches is that iteration across phases
is the norm, rather than the exception. So when an OO person uses the
term "iteration," they usually have a very specific idea in mind, i.e.,
a collection of activities resulting in the delivery of a complete or
partial product. No restrictions are placed on what these activities
might be.

Industrial strength software engineering approaches almost always
require some form of "change management." There are entire books
dedicated to this topic. Among other things, change management concerns
itself with such things as:

    - Clearly specifying what the change is.
    - Determining if the change is worthwhile/permitted
    - Tracking the progress of the change
    - Ensuring that the change does not conflict with any other
      requested changes
    - Introducing the change in a manner that ensures its effective
      implementaton.

Back in 1979, on a Citibank project, I witnessed firsthand the problems
with uncontrolled change:

   * Two different users contacted two different programmers at almost
     the same instant in time.

   * Unbeknownst to both the programmers and the users, each change
     invalidated the other.

   * In a room full of computer terminals, each programmer sat down at
     a terminal and began entering the changes.

   * When it came time to test the changes, the results were not what
     was expected.

   * Each programmer tried different ideas, and each programmer was
     continuously frustrated.

After the two programmers had wasted about 2 hours, they finally
compared notes, and resolved the problem.

Quote:> >Are there actually people out there that believe that all changes are
> >forbidden in non-XP projects?

> Forbidden? No, not forbidden. However I do believe that many projects
> place barriers to change, for example the requirement that business must
> get approval from development before bringing changes to the table (IE
> they have to *ask* for the change.)

One thing that impacts this viewpoint is who is paying for the change.
In addition, is the person or organization paying for the change
willing to pay the entire cost of the change, regardless of the
magnitude of that cost.

The XP approach, to my understanding, says the customer pays for
everything. So, if a customer just happens to ask for a change that
will require a substantial expenditure of resources, then the customer
will have to "pony up." They can have all the changes they want. It's
just more money in the developers' pockets.

Of course, if any change, or combination of changes, is extremely
detrimental to the product and the project, what should the developers
do? Inform the customer of the ramifications, or simply go on
collecting money until the project fails?

However, consider, for example, the fate of people working on
fixed-price contracts. The customer comes to the developer with the
original idea, and asks for a quote. If both the customers and the
developers agree, the project commences.

Now, what should happen if the customer decides that they want a big
change, but the customer does not expect to pay any extra for that
change? Do you think that development should have anything to say about
whether the change should be implemented?

Quote:> Also, the insistence of designers to
> not allow the customer to see the product in its nascent form (so that
> they less time to evaluate the system.)

This doesn't sound like a good idea. Virtually all projects I have
worked on in the past 20 years made sure that the customer could see
the product, or a prototype of the product, whenever they wanted to or
needed to.

Quote:> What we need is a methodology that explicitly states that the customer is
> always right, no matter how fickle or short sighted we may think him to
> be.

This methodology should also come with a "truth in advertising"
disclaimer informing the customer that they will pay for everything,
and that payment can be in many forms, e.g., money, time, product
quality, and product usability.

Quote:> If the customer turns out to be wrong, it's because the developer
> failed to give the customer the knowledge he needed. AFAIK, XP has come
> closest to this ideal.

From previous discussions with some XPers, I got the impression that
normally, XP does not have the requisite tools/methods/processes to
accomplish this goal. Now, of course, you can extend XP with whatever
is necessary, but you run the risk of moving very far away from
something you might call a "lightweight methodology."

Quote:> There are still, however, many questions. For
> example, I've read that the developers were being paid by IT (research?)
> but producing a product for Payroll. Who exactly is calling the project a
> failure, IT or Payroll?

This is a very legitimate question.

           -- Ed

--
**********************************************************************
Edward V. Berard                  | Voice: (240) 271-3777
The Object Agency, Inc.           | Fax:  

Gaithersburg, Maryland 20885-4116 | Home Page: http://www.toa.com/
U.S.A.                            |
*Consulting, Training, & Research in Web/Internet/Intranet Technology*

 
 
 

C3 dead.

Post by Blake Wint » Sun, 09 Jul 2000 04:00:00



>The XP approach, to my understanding, says the customer pays for
>everything. So, if a customer just happens to ask for a change that
>will require a substantial expenditure of resources, then the
>customer will have to "pony up." They can have all the changes they
>want. It's just more money in the developers' pockets.

Not as I understand it.  It's more that there's only a limited amount
of stuff that can get done, and the customer is free to choose what
they want done in what order, but that's about it.

Quote:>Of course, if any change, or combination of changes, is extremely
>detrimental to the product and the project, what should the
>developers do? Inform the customer of the ramifications, or simply go
>on collecting money until the project fails?

Regardless of what methodology you're using, as a professional you are
obligated to inform the customer that they are making a technology
unsound decision.  Perhaps they'll stick with it, for business
reasons, perhaps not.  Either way, it's their decision, and they
deserve to make it an informed one.

Quote:>However, consider, for example, the fate of people working on
>fixed-price contracts.  Now, what should happen if the customer
>decides that they want a big change, but the customer does not expect
>to pay any extra for that change?

Then the customer should stop smoking cheap crack. [0]
If they contract for something, then that's what they get.  If they
want something different, then they have to renegotiate the contract.
If it was otherwise, then I would contract someone for a simple shell
script, and then ask for a C++ program which solves the Halting
Problem, or some other suitably impossible task.

Quote:>Do you think that development should have anything to say about
>whether the change should be implemented?

No, but the schedule and fee should be renegotiated.

Quote:>payment can be in many forms, e.g., money, time, product quality, and
>product usability.

And frequently all four.

Later,
Blake.
--
10:23pm up 2 days, 23:06, 3 users, load average: 0.01, 0.02, 0.00

[0] It's a common expression around my office.  Take it with a grain
    of humour.  A rough translation is "The customer is crazy".

 
 
 

C3 dead.

Post by Daniel » Mon, 10 Jul 2000 04:00:00





>#>I don't what your "BigUpFrontDesign" is, but there are many RUP like
projects,
>#>that before beginning the guts of high level production coding,  investigated
>#>key use cases, outlined an overall architecture for achieving those use
cases,
>#>and had an iterative release schedule that replanned as necessary before each
>#>major iteration have shown themselves able to easily handle this.

>#You have just done a wonderful job of describing XP in a single paragraph.
>#Thanks for the input.

>??   Hey come on now.

> Neither Jeffries or RCM or Meijering agree with the need for an upfront
> planned overall architecture stance and RCM, or Meijering do not agree with
> the need to analyze all key use cases before commencing the heart of high
> level business coding.

Read _Extreme Programming Explained_ and you will find that in XP, before
beginning the guts of high level production coding, (or *any* coding for
that matter) the customer is expected to produce a list of all known use
cases/user stories (not just all key use cases). Development is then
expected to estimate the cost of *all* the use cases in time. Then the
customer produces a list of which use cases should go in the first release
(these are the *key* use cases.) Then development is supposed to have a
big party (meeting) where they outline an overall architecture for
achieving those use cases (define a system metaphor.)

Obviously, XP has an iterative release schedule that replans as necessary
before each major iteration (actually, the replan before *every*
iteration...)

Again, in or paragraph above where you attempted to "dis" XP, you
succeeded only in describing it...

 
 
 

C3 dead.

Post by Robert C. Marti » Tue, 11 Jul 2000 04:00:00



Quote:> Read _Extreme Programming Explained_ and you will find that in XP, before
> beginning the guts of high level production coding, (or *any* coding for
> that matter) the customer is expected to produce a list of all known use
> cases/user stories (not just all key use cases). Development is then
> expected to estimate the cost of *all* the use cases in time. Then the
> customer produces a list of which use cases should go in the first release
> (these are the *key* use cases.) Then development is supposed to have a
> big party (meeting) where they outline an overall architecture for
> achieving those use cases (define a system metaphor.)

Daniel, you are thinking a bit too sequentially.  XP does not demand that
all user stories be collected before coding.  Nor does it demand that all
collected user stories be estimated before coding.  All that is required is
for the customer to come up with the user stories that he thinks are most
important.  Developers estimate them as they are being produced by the
customer.  This is a pretty informal process.

At some point enough user stories are collected and estimated such that the
estimates add up to two or three iterations worth of work.  This becomes the
first release.  The customer chooses one iteration's worth of the most
important stories, and the iteration begins.

While the iteration is going, the customer continues to write stories as
they happen to cross his mind.  Developers continue to estimate them, and
the pile of stories grows.

--

Robert C. Martin    | "Uncle Bob"              | Training Courses:

PO Box 85           | Tel: (800) 338-6716      | Extreme Programming.
Grayslake IL 60030  | Fax: (847) 548-6853      | http://www.objectmentor.com

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

 
 
 

1. C3 dead.

I just noticed on Wiki an announcement that I'm suprised has not made
it here ( or perhaps it did and I missed it, in that case sorry). The
C3 project at Chrysler has been terminated. At this point, I don't
know any of the details.

2. CA Printer Sessions--HOW?

3. Linker strips "dead" code that isn't really dead

4. Dynamically Adding a button

5. Hear about Chrysler C3 at Smalltalk Solutions

6. WANTED: Sensible Soccer

7. to C3 participants

8. Help - GPF with HP660 driver

9. about C3

10. another truth from C3

11. 'Dead' message box

12. finding dead functions

13. DLL Detect Dead Process?