User:Atanamir/C3

The Chrysler Comprehensive Compensation System (C3) was a pilot software system originally designed to replace the payroll mainframe at Chrysler because of Y2K worries and overall system ineffiencies. Although it was never completed, it played a major role in rethinking traditional ideas and strategies for rapid software development. During development of the system, overall director Kent Beck implemented a software development strategy known today as Extreme Programming.

System Overview
The proposed system would replace the legacy compensation system at Chrysler, managing a payroll of 85,000 employees, collectively making up one-tenth of the United States gross domestic product. The developement of the system was being watched not only by administration, but by employees, their unions, the union leaders, and to some extent, some lawmakers as well. It was intended to integrate payroll from many redundant systems into one integrated system as well as be Y2K compliant.

Development History
The project was started in 1995 with a team of twenty-six developers. Development was slow for a year and a half, until finally hitting an obstacle. A constultant by the name of Kent Beck was called in to try to rescue the project, where he noticed many problems with the project's current state:


 * Contractual Arrangement
 * Exhausted people
 * Lowered voices
 * The project had lost sight of its goal, to print cheques to employees.

The major problem, however, was that the project faced developement in a task-oriented perspective: the system was treated as a set of tasks, and they tackled the tasks one by one. Kent Beck changed the developement strategy to a goal-based operation: instead of spending 18 months to complete the database operations, the team would instead focus on the end goal: printing a cashable cheque in as little as three weeks.

One of the main controversial tenets of Exterme Programming, as this developement method has come to be known, is the employment of pair programming - when two developers tackle the same task together on one workstation. This has led to constants conflicts about personality differences, productivity losses, and the development of senior/junior roles, a study by Laurie Williams at the University of Utah has concluded that "paired programmers are only 15% slower than two independent individual programmers, but produce 15% fewer bugs. Since testing and debugging are often many times more costly than initial programming, this is an impressive result."

However, the detractors believe that this result is only true with ideal pairs. Since the pairs are meant to change frequently, it is difficult to keep bad pairs from occurring. In the case of an expert-to-novice pairing, it is very natural for the expert to take on a tutoring role rather than a partner role in the respective pairs.

Another important practice that has become a tenet of Extreme Programming that was implemented in the C3 project was the breakup of the project into separate goal-oriented tasks. Instead of viewing each requirement as a single task to complete, Kent Beck had split each task into many small modules, each intended to be completed on a short schedule. At the end, each piece would be brought together to form the overall system.

This helps to promote another important aspect of Extreme Programming - communication. He frequently conducted one-on-one talks with each of the developers to get a sense of the progress of the project. Pair programming, too, depends a lot on the coaching system (the coach being the head developer, in this case, Kent Beck).

As Kent Beck said himself, the most important part of XP is t o "build systems that can absorb change". Thus the object-oriented features of Java were very important in this project as object-oriented encapsulation allows for massive change as it supports polymorphism, garbage collectors for all objects, and a compiler that is very careful in making sure quality code is written.

Conclusion
The project was finally discontinued in late 2000 due to the system's apparently being able to handle post-Y2K dates (a major factor in the decision to develop the new C3 system) and the project being over-budget and behind schedule (it was only paying 1/3 of the employees 5 years into development). However, many people still consider the project to be a success despite the cancellation because of the enormous turnaround the project made despite the monumentous obstacles slowing it.

Because of the "successful failure" of the project, the development strategy, named Extreme Programming, gained popularity and now is used and many companies and projects today. Extreme Programming overcomes many of the obstacles that often detract effective software development. It makes sure all development is goal-oriented and it tries to keep things simple. At one point, the C3 system contained as many as 2,000 classes and 30,000 methods.

Despite the incredible turnaround, it is impossible to ignore the fact that, in the end, the system was simply unable to successfully pay all 87,000 employees and the system subsequently was scrapped. The detractors of Extreme Programming often point to this outcome as the overall "result" of Extreme Programming: many small releases never culminate into one large release.

The C3 project is used both to promote and attack the practiced used by the development team; but nevertheless, the C3 project was important in that it introduced a new method of software developement into the world that has become widely used today and has a strong following of both supporters and enemies. In short, Extreme Programming promotes the following principles of software developement:
 * Simplicity - view each requirement as a set of sub-tasks and focus on a single task at a time. However, don't lose sight of the overall goal: results and execution.
 * Paired Programming - Based on the two-heads-is-better-than-one principle, pair programming can help prevent bugs, increase producitvity by producing less bugs, and increase overall teamwork.
 * Communication - By splitting the developement teams off into pairs and splitting each requirement into many small tasks, communication is a very important principle as project status and developer morale must be constantly assessed.

References / External Links

 * The Chrysler Comprehensive Compensation System
 * Working smarter, not harder: An interview with Kent Beck
 * The Dangers of Extreme Programming
 * Will Pair Programming Really Improve Your Project?
 * "Agility Counts". The Economist Print Edition.  September 20, 2001. 
 * Haungs, Jim. "Pair programming on the C3 project.(Chrysler's Comprehensive Compensation project)." Computer 34.2 (Feb 2001): 118(2). Expanded Academic ASAP. Thomson Gale. UC Irvine (CDL). 18 October 2005 .