Thoughts on Extreme Programming

Another important point is that soon or later one needs to test the software by writing a number of small tests. Why not to write them in advance? It would definitely save time and resources. Unit testing – one of the best concepts of XP can help here.

User Stories

Giotto’s Circle. Pope Benedict XI sent an emissary to obtain a sample of the Giotto’s work in order to evaluate his skill. Giotto smiled, took a sheet of paper and with one twist of his wrist drew a perfect circle freehand.

While Giotto has extraordinary talent, in order to draw a perfect circle I need a tool. Otherwise I’ll draw irregular circle. Filling in this irregular circle will again create a waste and a lack.

In classical methods this tool would be Requirements. In XP, this tool is a User Stories (or just Stories) practice. Stories describe what to do in a very short manner, maybe one sentence. By putting stories on an index cards and having them on the same table it’s easy to visually group, prioritise and estimate them together with a customer. It’s good practice to pick up most important stories to do first in order to eliminate risk early in the project. It is hard to do this in case of requirements while you have to extract important tasks first.

Weekly Cycles

XP proposes dividing development into Weekly Cycles. For me, weekly cycle is like a day from a human life. As soon as we wake up in the morning we plan what to do during a day – have breakfast, go to work, meet with customer, have lunch, and so on. Having Monday meetings in XP is the similar planning activity. All day along, we do what we planed. Finally, in the evening, if we accomplished all of them we are happily going to sleep. XP team will go proud for the weekend as well, if all tasks done. Although, I think that there are people who live in plan driven way (not agile or extreme), planning all activities for a months in advance.

Weekly Cycles are very natural. However, they not necessarily should be a weekly. A “day” can last a week, two weeks or even more. I think the most important part for XP team is to go to sleep on weekends. Otherwise, development cycle will look like a shifted work day when people work at nights and sleep in the afternoon. Productiveness of night work is always lower that productiveness of day work.

Informative Workplace and Sitting Together

Yet another very useful practice is an Informative Workplace, especially, usage of the wall. Putting index cards on the “informative wall” creates a clear development process measurement tool, which personally I missed along all my experience. It is so hard to explain and so often asked by the management people: “Where development process is at the moment?”. Now I can just show them a wall. Team members also benefit from it by gaining a sense of the progress.

However to make it work, all team members should seat in the same room. Sitting Together practice addresses exactly this benefit. Team members sitting in the same room, even better behind the same table, communicate much better. One may find this disturbing. However, there are more advantages rather then disadvantages.

Ten-Minute Build

Ten-Minute Build is a dream of development teams. Fine tuned automation of compilation and testing (remember Unit Testing?) procedure will decrease defects and increase whole speed of the process. However, initial setup and tuning of such system may take weeks and may be not efficient for short development projects. In my opinion, to build “Ten-Minute Builds”, all compilation, tests and consequentially all code should be centralized. Thus, Ten-Minute Build primary practice probably implies Single Code Base corollary practice in it.

XP Cons

Despite popularity of XP method, not everyone thinks that XP is a good idea. There is an army of developers (mostly developers, not other team members) unsatisfied or against XP. However, criticisms seem to be focused on few practices.

Pair Programming

Googling for XP practices returned abnormal number of negative comments on this method. Most of complaints were about Pair Programming practice, argued mostly by that company should trust professionals. In XP, Pair Programming is the primary and unique practice which proposes putting two developers in front of one keyboard. Arguments seem very convincing and pair programming is really controversial.

Even in its book, in the interview with … , author writes: “If programmer won’t pair or if they insist on owning code, have the courage to fire them. The rest of the team will bail you out”. Quite American way of working… But what if you can’t just fire them?

To get more figures on Pair Programming I would suggest reading the following:

• A. Cockburn, L. Williams “The Costs and Benefits of Pair Programming”
• L. Williams, R. Kessler “Pair Programming Illuminated”

Based on the real cases and interviews the first article advocates and highlights variety of PP advantages leveraged by statistical information.

Second book – PPI divides programmers into different categories and then discusses the possible effects. The programmer categories are novice, average, expert, introvert, and extrovert. And the possible combinations are:

• Expert-expert
• Expert-average
• Expert-novice (watch while I type)
• Novice-novice (unsupervised!)
• Extrovert-extrovert
• Extrovert-introvert
• Introvert-introvert

In the other book, which actually has been written against the 1^st edition and called respectively “Extreme Programming Refactored: The Case Against XP” authors M. Stephens and D. Rosenberg point out following weak areas of Pair Programming:

• Pair programming is necessary in XP because it compensates for a couple of practices that XP shuns: up-front design and permanent design documentation
• Pair programming is definitely not for everybody. I don’t want to share my desktop with anyone!
• In a real project, “solo” programmers don’t really code alone; they’re part of a team. Typically, designs are reviewed by senior engineers who sign off on them.
• If you’re working on something that is so complex that you actually need to concentrate, you need silence.
• Most of us are willing to share (i.e., peer review) but we do not want to show our ‘stuff’ until it is ready. It is just human nature.

On-Site Customer

Too much customer’s responsibility: schedule is the customer’s problem, requirements are the customer’s problem. The customer seems to have lots of problems. But isn’t that the key idea behind agile mehotds?

More Information

• eXtreme Programming
• XP on WikiPedia
• About Kent Beck here and here