On Fri, 5 Mar 2004, Frank Barknecht wrote:
So, maybe the "non-Extreme Programming" advice I would give is: "Sit down and think, before you patch." Actually I got this advice once from Kim Cascone, who said it in a slightly other way like: "Make a detailed plan before you develop something and by all means: Stick to it!" The last part is the hard part.
A more Extreme Programming way of dealing with creating patches would be like:
prototype as you go, the way you feel it, making sure you have add something useful AND working, and make sure your code doesn't stop working for extended periods of time
when you get enough experience with the problem that you now have an idea about how to make a part of your patch cleaner, _do it_.
especially, any kind of duplication of effort and copypaste programming should be destroyed right after it's created, and replaced by something cleaner.
when you make an abstraction, also provide a patch that can automatically test it and report whether it works. create the testing patch before the actual abstraction (!). Whenever there is a bug, add something to the testing patch to test for that bug, and only then fix the bug so that the testing patch stops complaining. Use your testing patches as your bug database as much as possible.
Mathieu Bouchard http://artengine.ca/matju