My adventures with Extreme Programming


Once again its been a long gap since I last blogged on this blog. But somehow today I couldn't stop myself from blogging. Thanks to my colleague in Tesco UK, David Kiff who was generous enough to say that I write some technical stuff on my blog. I think David is far more accomplished blogger than me and I always appreciate him for his enthusiasm.
I would like to share my experience with Extreme Programming or XP so far.

Its been close to a year since I was exposed to it. I am fortunate to be a part of a wonderful team involved in development work for one of the top retailer Tesco in UK. Me and my team work out of Bangalore office. I was fortunate to be one of the two members of the team which was formed about a year back and since then it has been growing at a good pace.

My first exposure to XP came when I was in UK for about 3 months during April-July 2008. It was part of knowledge sharing sessions that we had during my stay in UK, that I was involved in various activities like morning scrum or daily stand ups, iteration planning meeting, unit testing, pair programming etc. It was a great learning experience. We have been gradually implementing these processes in our projects back home in India.

As they say, change is the only thing which is constant. Initially it was difficult to get used to a different process. Having worked in services industry in my previous organisations it wasn't an easy thing. At times I was thinking all these guys must be really crazy to tell each other what they did yesterday and what they plan to do for today. It was funny to see groups of people standing every morning daily and narrate their plans for the day. It was like a punishment, it reminded me of the old days in school where we had to stand in line for being late outside the school gate.

The team I was working with was following the process of Continuous Integration using CruiseControl.Net. Every time there was a build error somebody named 'Build Master' would come running to you and ask you to fix the build. The other developers were prohibited from checking in their code to source safe until the build was fixed by the person who broke it.
Then there were these weird planning meetings called Iteration Planning meeting which was used to plan for work worth of only 2 weeks. It sounded most weird because I was used to seeing my team lead and manager break their head using MS project planning for project months in advance.

If all these things were not enough then there was concept of Pair Programming. Two developers were working on same machine developing same piece of code. To a certain extent it was fine that they were trying to develop something taking each others help, but then they were also testing the code using unit tests. I felt testing was a job of test team and developers shouldn't be doing any of the testing work.


By the time I returned from UK after spending 3 months, I was enlightened with the benefits of various processes that were used within the Instore team for development work. For all those folks who are not aware of extreme programming please refer to David Kiff has written nice article on why bother pair programming. I agree with David's thoughts. Continuous integration (CI) is another thing which I personally like about XP. Contineous Integration by Martin Fowler is a wonderful article. Its always helpful if we as developers get to know about the problem as soon as we make the smallest change. I have been advocating use of unit tests in development work that we are currently doing. I have just started reading a book on xUnit Patterns.
There are few people in my team who have not yet realized the real value of writing a quality code using unit testing but someday I hope I'll be able to convince them to take up to unit testing.

Some of the benefits of unit testing which I have ripped during short duration are:

  • It helps in localizing the defects
  • It helps in better code coverage
  • It provides a safety net for future development
  • It acts as documentation which is in synch with code
  • And most importantly it gives confidence to the developers about the code they have written.
Unit testing in itself is a vast topic. Hopefully I'll get inspired again to write another post on things like code coverage and details about unit testing.