Extreme Programming:

Almost everyone who has ever been a part of a software development team has experienced a sense of anger, frustration and helplessness at how “things just get out of control”. Unlike manufacturing, software development process grants each person the potential to completely wreck the product cycle with an unwitting minutest intervention. Is this a person or a process problem? Why do software development projects fail? How can we alter the process of development to make it less sensitive to the actions of the people involved in it?

Appian sponsored Java Users Group (AJUG) decided to find answers to these questions by looking at the alternate software development methodologies. We started with looking into details of Extreme programming – first proposed by Kent Beck. His book, "Extreme Programming Explained" is broadly divided into three parts – The Problem, The Solution and The Implementation, each of which is about 50 pages. On a Saturday afternoon it will take you less 3 hours to go through the whole book.

Kent recommends paradigm shift in software development process. The emphasis is on designing little, implementing, testing and repeating the process as fast as possible. This is completely antagonistic with the most technology team’s emphasis on designing early and thoroughly. The book strongly recommends use of XP methodologies like pair programming, unit and functional testing, which definitely have a lot of positive points. Kent also provides a rather simple yet remarkable way of cost benefit analysis of adding a new feature during the various stages of product life cycle. Unfortunately in one and half pages the idea is bit under sold but then this is not a book about pricing software.

One of the most intriguing ideas put forth is the concept of common ownership of code. Most technology projects have core of their architecture closely guarded under the watchful eyes of their most senior programmers. Kent makes a strong case for allowing every member on the team to make any change they deem necessary to any part of the system. At first this seems completely illogical and fraught with risks, but he explains that with pair programming, automated testing and refactoring its not as perilous as one would wonder. The left liberal in me is convinced but the pragmatic one tells me that the risk involved are highly dependent on the ability of every member of the team to understand the architecture and also on the quality of the automated tests. Weakness in any of the two can end in some disastrous consequences. I have spent sleepless nights (not quite) thinking about this, but I am still not convinced. Common ownership is highly depend on the XP methodologies and cant be put to practice unless other XP stuff is working very well for the team.

Overall this book is worth every penny of its value. You might not agree with any of its ideas, but it does provide some fresh insights on tackling problems we face on a daily basis. It’s not a fast paced suspense thriller - DaVinci code, but it’s closest to that in the world software engineering. I will specially recommend it to the people who are disturbed by the chaos and confusion surrounding development of software products and are looking for more repeatable and predictable processes.

I do agree with the Kent about this -- Embrace change!