"Refactoring is a fix-it-after-its-happened strategy. In our company that has turned out to be far more costly than just doing proper planning to begin with." That's the case if you wait to long before you refactor. In XP you divides engineering tasks up into baby steps. First you write a test. This should take no more than a couple of minutes, usually much less. Then you write code for a couple of minutes. The tests tell you when you're done. Then you clean up your code using XP very high standards for code quality. You repeat this for all baby steps.
Planning is a very important part of XP. XP does planning by playing the "Planning Game". See http://www.extremeprogramming.org for an excellent overview.
Analysis and design is done through "merciless refactoring". It turns out to be very hard to convince some people that this is not hacking.
XP has very high standards for code quality. See my home page for examples of XP code (http://www.wi.leidenuniv.nl/~mmeijeri). I hope you'll agree this is not horrible code.
At the same time many people who do believe that this will work because that's "what they've been doing all along" are probably not doing it mercilessly enough.
Showing people how to do it turns out to be easy though. A while ago on otug and comp.object I suggested doing a XP demo via MS NetMeeting and I got a lot of positive reactions. Setting a time and date turned out to be hard. If any of you want to give it a try, try to reach me with NM at 194.151.45.193.
"Isn't that just wonderful, more headaches. I see this all too often. This is why one should insist on good, complete specifications. Have the customer sign the specs and an agreement to have the work done. When they come back with "little changes," the answer ought to be: You've agreed to this specification. You will be shipped this product. Any changes to the product will be made as enhancements to the already shipped product, and will be specified, estimated, and billed accordingly. "
In a way this is what XP does. However, every (1 to 4 week) iteration results in a release. So customers get what they pay for very regularly. Then there is no need to insists on good, complete specifications, which is a good thing because there is no such thing as a good, complete specification up front. The great thing about this is that it takes away the mistrust. You don't have to worry about the customer changing his mind at your expense and the customer doesn't have to worry about sinking money into a bottomless pit. Customers are part of the team. The customers continually try their best to come up with the best business value they can think of and the programmers do their best to deliver as much of that as they can. See http://www.xprogramming.com/products.htm for more about the customer-developer interaction.
"That may very well be, but when you're starting on a project from scratch. You have to have something to work with. You can't start from nothing, or are you Yuri Geller? " In XP functionality is determined by stakeholders in (verbal!) discussion with the whole development team. This way everybody has a good understanding of what needs to be done. For scheduling and estimation the functionality is recorded as user stories on cards. During implementation of a user story, the developers involved go talk with the stakeholders for more detailed information. No later than halfway through an iteration the stakeholders (supported by developers) come up with detailed tests. They serve both as detailed specification and regression tests. For a very tiny but readable example, see the payroll exercise on my home page (http://www.wi.leidenuniv.nl/~mmeijeri). For a larger example, see the compiler project on the same page.
The point about talking is very important. Having someone looking over you shoulder is not what we mean by pair programming. Pair programming is about synergy, not distrust.
The proponents of XP do not claim that it is for everyone or for every situation. See http://c2.com/cgi/wiki?ExtremeProgrammingProjects for descriptions of projects using XP. I've been using XP in C++ for the last year and I think it's great. There are a couple of examples of XP in C++ on my home page (http://www.wi.leidenuniv.nl/~mmeijeri).
Fortunately, what you describe is not the way Extreme Programming works. See http://www.extremeprogramming.org/rules/planningga me.html for how XP does planning.
Slashdot Mirror
"Refactoring is a fix-it-after-its-happened strategy. In our company that has turned out to be far more costly than just doing proper planning to begin with." That's the case if you wait to long before you refactor. In XP you divides engineering tasks up into baby steps. First you write a test. This should take no more than a couple of minutes, usually much less. Then you write code for a couple of minutes. The tests tell you when you're done. Then you clean up your code using XP very high standards for code quality. You repeat this for all baby steps.
Analysis and design is done through "merciless refactoring". It turns out to be very hard to convince some people that this is not hacking.
XP has very high standards for code quality. See my home page for examples of XP code (http://www.wi.leidenuniv.nl/~mmeijeri). I hope you'll agree this is not horrible code.
At the same time many people who do believe that this will work because that's "what they've been doing all along" are probably not doing it mercilessly enough.
Showing people how to do it turns out to be easy though. A while ago on otug and comp.object I suggested doing a XP demo via MS NetMeeting and I got a lot of positive reactions. Setting a time and date turned out to be hard. If any of you want to give it a try, try to reach me with NM at 194.151.45.193.
In a way this is what XP does. However, every (1 to 4 week) iteration results in a release. So customers get what they pay for very regularly. Then there is no need to insists on good, complete specifications, which is a good thing because there is no such thing as a good, complete specification up front. The great thing about this is that it takes away the mistrust. You don't have to worry about the customer changing his mind at your expense and the customer doesn't have to worry about sinking money into a bottomless pit. Customers are part of the team. The customers continually try their best to come up with the best business value they can think of and the programmers do their best to deliver as much of that as they can. See http://www.xprogramming.com/products.htm for more about the customer-developer interaction.
"That may very well be, but when you're starting on a project from scratch. You have to have something to work with. You can't start from nothing, or are you Yuri Geller? " In XP functionality is determined by stakeholders in (verbal!) discussion with the whole development team. This way everybody has a good understanding of what needs to be done. For scheduling and estimation the functionality is recorded as user stories on cards. During implementation of a user story, the developers involved go talk with the stakeholders for more detailed information. No later than halfway through an iteration the stakeholders (supported by developers) come up with detailed tests. They serve both as detailed specification and regression tests. For a very tiny but readable example, see the payroll exercise on my home page (http://www.wi.leidenuniv.nl/~mmeijeri). For a larger example, see the compiler project on the same page.
See http://www.cs.utah.edu/~lwilliam/Papers/ieeeSoftwa re.PDF
The point about talking is very important. Having someone looking over you shoulder is not what we mean by pair programming. Pair programming is about synergy, not distrust.
The proponents of XP do not claim that it is for everyone or for every situation. See http://c2.com/cgi/wiki?ExtremeProgrammingProjects for descriptions of projects using XP. I've been using XP in C++ for the last year and I think it's great. There are a couple of examples of XP in C++ on my home page (http://www.wi.leidenuniv.nl/~mmeijeri).
Fortunately, what you describe is not the way Extreme Programming works. See http://www.extremeprogramming.org/rules/planningga me.html for how XP does planning.