I read through Kent Beck’s Extreme Programming Explained these past few days. Extreme programming (XP) has a misleading name. It’s not just about programming, it’s a far reaching software development concept that goes beyond the folks doing the programming. I’ll go over a few things that stood out to me.

Extreme programming is a type of agile software development. Both Extreme and Agile itself stresses the importance of communication. There is this focus on communication because as Kent Beck puts it in the book: technical problems on a project is always a people problem. You help to solve that by communication, whether it’s communicating with your coworkers, manager, other stake holders in the company, or the customer. I’ve used other software development processes in the past and worked on teams where there is a firewall between you and the customer, or just a lack of communication with the customer. Often times the result is delivering something that the customer does not want, far into the project. Solution? Talk early and often.

With that comes the next important thing XP stresses: short feedback cycle. Feedback here means many things. Feedback from people, teammates to customer. This means working in short sprints, one or two weeks. Like the book, I prefer 1 week sprints. I feel that you break down problems finer if you work in 1 week sprints. And you get to communicate this earlier with people. 1 week sprint does not mean that you communicate just once a week. You communicate as often as needed, as early as needed if problems arise.

You also want a short feedback cycle from the code itself: is it doing what you think it’s doing? For code, there are many techniques involved. First is the importance of doing Test Driven Development and having unit tests and actively testing as you go. You don’t wait for the QA team to test, test first to guide you as you develope/design. Also important is integration testing and continuous integration through automation. You want to see if things are working as soon as possible, or if they are breaking as soon as possible. Sometimes this means weekly deployment of production code. Sometimes it means daily.

With that said about fast feedback, right now I don’t see that with my current client, even though they do weekly scrums. With this client, it’s a fairly large company where there is a clear separation of responsibility: the developers develope, testers test, and builders build/deploy. Feedback is not as fast as it should be because most on the team don’t do unit test so even though code may appear to work, problems are often found much later when it goes to QA or even later when it goes into build.

One last thing I want to talk about is XP’s focus on pair programming. I’ve been pairing for the past 2 months and I’ve come to really like it. When I first heard about pair programming, it felt like it would not be productive. How can 2 guys on 1 keyboard be productive? First time I tried it 2 years ago it was eye opening. I paired for 14 hours straight that day (hard deadline, I think I was at the office 18 hours straight that day, 6am to past midnight). The work done was easily weeks worth if I did it on my own. It was a lot of communication between my boss/mentor and I. A lot of catching each other’s mistakes before we even compile. Saved a lot of time. One drawback was that we didn’t unit test or else it would have been much better. The past 2 months, we’ve been working more or less the XP way. We pair, but we do TDD. The code is clean, focused, with tests to back it up. The contribution we have to the project is significant and we work at a much faster pace than the rest of the team.