I went to the Chicago Java Users Group meeting last night. It was pretty interesting. The speaker was Bob Martin of Object Mentor, speaking about “agile development methods”, of which XP is the most common. If I had this guy give this talk to me, I would have been far less skeptible about XP than I have been. Of course, as implemented in my workplace several critical components were missing that made all the difference between success and fiasco. The key points that I saw were:
- Do the estimation in abstract relative terms (story points), not in time units. Then actually do development and see how many story points you can do in a week, which normalizes the abstract points into actual development units and allows for reasonable estimation of when the project is done.
- Do a weekly introspection on the project, seeing how many points were done in the previous week. Then allow the stakeholders to choose that many points worth of stories to be the ones completed this week.
- For test-driven development, be so rigorous that it feels stupid. Do not ever touch source code except to make a unit test pass. Write one or two lines of test code, and then the minimal source code to make the test pass. This cycle should take a minute or two apiece. Don’t code for three hours and then try the tests. You should never be more than a few minutes out from a working test, so it should never be a huge deal to fix it. This gives you complete unit test coverage of your code, and moreover means you never write any untestable code.
I’m willing to back off of my eXtreme Placebo comments of the past and give some of this a shot, particularly the test-driven development. It will require some discipline, but it certainly seems like a good way to go. Having lost hours to trying to figure out snaky spaghetti code lately, it would be nice to have that sort of thing be unnecessary.