Five Lessons you should learn from Extreme Programming. This was posted to the XPToronto mailing list. I’m a bit of an XP sceptic. I think there are some good practises, but some of them I can’t adhere to. I’ve never been a total supporter of peer programming. I do think it’s a great idea and it has its benefits (no code ownership, peer review, learn coding by watching others) but I also couldn’t sit there and watch someone program. It would be a mental struggle for me to sit beside someone and pay attention to watching them code. I’d like to try it out with a senior programmer someday just to see their technique and see how others work. But there’s no way I could do that daily. I can’t sit still like that.
Test-first design is great. And I really try to adhere to this in personal projects. Continuous Integration is essential. Daily (if not more) automated builds are crucial to a successful product. At my last company, the first thing I did when I got in there was automate the build process. Previously, it was a mish-mash of manual steps on different machines to build a Win32 client. VB6 compiling plus Installshield creation. There was a small sheet of instructions on how to do the build manually and this was out of date. So I created a full set of ant scripts to automate everything. It made everyone’s lives easier once this was completed. Just don’t ever ask me to work with VB again…compiling with dependencies is ridiculous. Blagh.
And who doesn’t like the practise of a 40-hour week?