5 Lessons from XP
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? 
July 7th, 2004 at 6:15 am
When pair programming, you should definitely NOT sit there watching your partner code when you are not at the keyboard. You should take an active role in the work and take responsibility for the larger scale design decisions that your pair cannot think about while they are concentrating on the smaller scale decisions.
July 7th, 2004 at 8:43 am
Have you ever pair-debugged? If so, pair-programming prevents the need for pair-debugging
July 7th, 2004 at 11:44 am
Pair programming… I can see it now… terrible… I don’t want to think about it any more… most of the people in my company can’t code crap…
I would hate to help them hobble along as they struggle to replace massive if…then…else blocks with switches or loops and data structures…
No my friends, peer-review is important, but it should be done in a formal process where changes are discussed and argued and higher logic preveils… When shitty coders refuse to accept logic that is an improvement over there (because of ego, pride or whatever) they should get shit-canned. The brave and the smart don’t fear their peers input/dicussion and those are the kind of people you want working for you.