Extreme Programming

Extreme Programming (XP) is arguably the hottest methodology in the Agile bunch. Entire libraries of books have been written about it in the last 10 years (if that long). Lately it appears to be dropping off the trend radar, but the boost it gave to Agile Methodologies ensures it will not fade away anytime soon.

XP consists of 12 Core Practices:

• The Planning Game
• Small Releases
• System Metaphor
• Simple Design
• Test-Driven Development
• Refactoring
• Pair Programming
• Collective Code Ownership
• Continuous Integration
• Sustainable Pace
  
• Onsite Customer
• Coding Standard

Now, some of these are things that nearly every development group will take as a given - Coding Standards and Collective Code Ownership, for example, are common. Others are likely to run into heavy resistence, either from the developers themselves, or from the management above the developers. Pair Programming often runs afoul of both groups; programmers are accustomed to working solo in many cases, while managers dislike the appearance of half their staff not working.

Refactoring is one of the hardest to explain to a non-programmer. As every developer knows, the design as originally planned never quite matches the code that you end up with. Reality forces numerous small deviations from the blueprint, and so the end product is full of hacks, compromises, and cruft. So developers need to spend some time periodically reorganizing the code structure and clean out the digital dust bunnies.

The problem is that managers often don't want working code to be touched, and since refactoring is intended to change the code structure without altering the function, it can be difficult to get buy-in for it. The best suggestion I have heard is to use Rube Goldberg as the metaphor - his contraptions worked, but they were hardly streamlined. A little time to replace the cats, candles, and buckets with motors, switches, and tubing, and voila!, it works, better.

Sustainable Pace is another one likely to stick in the craw of management. In XP vernacular, this means a 40-hour week, all the time. No Death Marches, no 80-hour-weeks, nada. XP holds that with all the Core Practices in place, the team should not need to work overtime. As far as I can tell, current American management is quite unlikely to accept "No, we're all going home at 5", if there is work left to do, especially if there is a deadline looming. Having been part of at least 2 Death Marches, and one pre-planned Zombie Stroll, I can attest to the diminishing returns of 60-80 hours a week for more than 2 weeks.

Onsite Customer is the one practice that I feel is hardest to introduce. Too many development shops are kept away from the customers because the managers feel uneasy with the developers in close proximity to the customers. Others have the problem that they have more than one customer with differing needs, so that it is difficult to reconcile all the customers' needs. Also, few customers want to dedicate a knowledgable staffer to the project for that much time - they'd rather throw a few hours into a RFP-style document and have the development shop do all the work from there, until the time for testing arrives.

---

Technorati Tags --
Software
SoftwareDevelopment
Computers
Programming