is the extreme programming created because the software product is so easy to have bugs? so they suggest there should be two person programming together?
I've been ignoring the concept of Extreme Programming until today when I read a review for a book on the subject. I was surprised to find that Extreme Programming seems to be very similar to a software development process that I used while managing a software group at a semiconductor equipment company. After working there for several years as a programmer I understood that the practice of having new hires work alone simply was not productive. They usually required a couple years to come up to speed on our product. Since the turnover rate for engineers was closer to eighteen months it was clear that working alone wasn't a good idea. When I was offered the opportunity to setup a new software department in the service organization I hired an equal number of entry level software engineers out of school and machine hardware experts from the manufacturing and service organizations. The idea was to have the hardware people learn C language programming from the software engineers and have the software engineers learn the operation of the machine from the hardware experts. Very quickly the two man teams proved to be amazingly productive. Prior to the creation of my department, the company shipped a new version of software every 18 months. Since a software bug in the semiconductor industry can easily cost the customer tens of thousands of dollars each day, the 18 month cycle time was devastating. Even worse, new features intended for customer A often created problems for customer B. We found that an improved process was to immediately ship new features and bug fixes directly to the customer that requested the modification. The result was customers that got their modifications at the earliest possible date and the other customers got fully tested code at a later point in time when they decided to upgrade. The incremental code releases occurred as needed and averaged about once every two weeks. Each new version of code was built on top of the previous so integration occurred continuously. The release process for a major code release was nothing more than an exercise in paper work that simply glorified a previous incremental release. The engineers in my department all worked very closely with the customers and our applications engineers and field service engineers to improve quality on a daily basis. I left that company two years ago. It's funny that it has taken a couple years to learn that our process now has a name.
Dan Chisholm<br />SCJP 1.4<br /> <br /><a href="http://www.danchisholm.net/" target="_blank" rel="nofollow">Try my mock exam.</a>