from: www.extremeprogramming.org
The author of this website is Don Wells. He learned about how teams become unproductive while at Honeywell and General Electric. He then learned a great deal about teams becoming super productive while building expert diagnostic systems for the US Army and Ford Motor Co. Many artificial intelligence practices are now common in software development.
The turning point in current software development came in the mid-1990s. Many people were re-examining the idea that software must be built like hardware. Jeff Sutherland and Ken Schwaber were formalizing a new process called SCRUM. Alistair Cockburn was working on Crystal Clear. Chrysler was doing its part by trying to build traditional business systems using object-oriented technology. This is a common approach now that Java is used in almost all domains, but was very advanced in the previous millennia.
Don was hired on to the Chrysler Comprehensive Compensation (C3) project as an expert in object technology and GUIs. It didn’t take long for him to spot some serious trouble. The team was splintered into 3 groups that worked in competition instead of cooperation. The project was becoming overdue. Estimates were showing it way over budget. It was also way too complex and riddled with redundant code (Conway’s Law) to ever work reliably in production. His assessment of the situation was to start over. There was time to make the deadline but only if the team worked together in cooperation and sharing as opposed to competition and isolation.
You can probably imagine that starting a project over after millions of dollars were already invested is a tricky situation. Don had to wait for exactly the right moment. That moment came when a consultant named Kent Beck was hired to optimize the C3 system’s performance. Kent decided to spend a half hour with each of the developers to get an idea of what needed to be done. When he began talking to Don he ended up spending 3 hours. At the end of that time Don had convinced Kent that the current code base would never make it into production. Kent presented that result to Chrysler management and they agreed.
The project was halted and Don began not just mending fences but completely tearing them down between team members. Chrysler management noticed what he was doing and offered him the position of chief architect. Don graciously refused while explaining his concept of everyone owning and contributing to the system’s design. No one understood his goal yet.
Kent Beck was hired to spend a couple days each month on the C3 project. Chrysler also hired Ron Jeffries to join notable agile proponents Martin Fowler and Chet Hendrickson on the project. Kent mixed together the best practices Don Wells is on the left from several emerging agile processes with things he had learned while working with Ward Cunningham. The C3 team created a new process formulation by watching what helped or hindered. Doing more of what helps and less of what hinders resulted in a minimal process with high flexibility.
Kent wanted the team to integrate code often, but it wasn’t working. Kent had appointed an integration czar with integration lieutenants in a hierarchy. Integrating that way put a chief architect back into the project and slowed them down till they were integrating once every three weeks and taking days to do it. A hot spot of complexity was also brewing. Don came up with an idea. It would solve the current integration problem, allow design simplifications, and lead the team to his ultimate goal of collective ownership.
Don proposed to the team that they set up an extra computer on an empty desk where all integration would take place. They would integrate and release new code to the repository when ever they wanted without prior permission so long as it ran all the unit tests. Management hated the idea. The team was mixed about it. Management played their trump card by not allowing Don to have an extra computer. So Don simply moved his own computer to the empty desk and told everyone it was the integration station. He wanted to do more pair programming anyway.
That simple change made a huge difference. People began releasing code at least once a day if not more. Sharing an integration computer made people more cooperative and the design tighter because everyone was responsible for making it better. Anyone could change any code and know changes would not be lost. People began writing more unit tests then they had before because it ensured their code would run even if some one else made some changes.
The real prize in that change was what came to be known as collective ownership. The entire team owns the entire code base. The entire team is responsible for developing and extending the system design. The team worked together cooperatively at a much faster pace than anyone expected. Don has some rough estimates and believes the team was going six and a half times faster than before the project was restarted.
With C3 back on schedule Don moved back to Ford Motor Co. This time he was to help a financial application get back on track. The application was the Vehicle Cost and Profitability System (VCAPS) that calculated how much it actually cost to build a car or truck. It was in trouble because of serious quality and performance issues. More time was spent fixing bugs than adding required features.
The first big change Don made was to write a unit test framework and create the first unit tests. It was a “white knuckle” assignment because he had two weeks to write code and one week to debug. The unit tests and framework took the entire first two weeks to finish. But once the unit tests were in place the actual code only took one week to write, no debugging needed. The assignment was brought in on time with none of the expected bugs. This was a good start.
As the number of unit tests grew management noticed a one third reduction in production bugs. At that time Don was able to set up an integration station and began continuous integration and collective ownership. More Extreme Programming (XP) practices were introduced until the second XP project was running. As production bugs dropped even further the team became more productive eventually reaching a factor of ten times. This second XP project verified that XP was a viable process and C3 was not just an anomaly.
Soon after leaving the VCAPS project in 1999 Don created this website. At that time information on the XP process was either very Extreme Programming Perspectives XP Agile Universe 2002 XP Agile Universe 2003 confusing or biased towards Smalltalk projects. There was also a great deal of discussion going on about whether or not XP would even work. Don perceived a need for a simple explanation of the basics that everyone would agree upon. Having been on two XP transformations he felt qualified to be the author.
