Extreme Programming


There's been a lot of buzz about Extreme Programming, or XP as its sometimes called. Proponents claim that its the answer to late projects and buggy code. They might be right. A recent Wired Magazine article called The New X-Men talks a bit about XP and highlights four programmers at HP's Seattle office. One of those developers is Kevin Yu, described a s 25-year old, prematurely jaded programmer:

Yu is among thousands of coders who've discovered extreme programming, a method of software development that emphasizes constant feedback. Traditional coding devotes a huge amount of time to up-front planning, then demands rigid adherence to that plan. XP is different. Programmers spend relatively little time planning and instead dive into the writing, making course corrections as needed and allowing better ideas to emerge after snippets of code are tested and assessed. The result is a speedy loop: plan, code, test, release, plan, code, test.

At the heart of XP are some simple concepts and principals. The Wired article, following the lead of an article on IBM developerWorks by Roy Miller called XP Distilled, defines twelve rules for XP:

  1. The Planning Game XP is based on the assumption that you can't know everything upfront and that you'll learn as you code. This XP encourages the creation of a rough plan and then frequent updates as you go along. This involves constant communication and frequent meetings with the customer.
  2. Small Releases Put a simple system into production quickly, then release new versions on a short cycle. Even so, each release should deliver real business value.
  3. System Metaphor This is XP's answer to architecture. The system metaphor provides a picture of all the pieces and how they interact.
  4. Simple design Simple designs lead to simple implementations. The implementation should pass all the tests with a minimum amount of code and no more.
  5. Testing Writing unit tests is part of writing the code in XP. In fact, the test is written before the code and serves as the specification. The customers write the acceptance tests. How is that possible? See my write-up of Ward Cunningham and Brian Ingeson's talk on the FIT Framework for one possible answer.
  6. Refactoring Refactoring is rewriting the code to simplify, add flexibility, or remove redundancy without changing the functionality. An XP team refactors relentlessly.
  7. Pair Programming Write all code with two programmers at one machine. Some might think this inefficient, but Martin Fowler says "When people say that pair programming reduces productivity, I answer, 'that would be true if the most time-consuming part of programming was typing."
  8. Collective Ownership Any person on the team can change code anywhere in the system at any time.
  9. Continuous Integration Rather than scheduling daily, weekly, or even monthly builds, XP proponents build the entire system several times throughout each day to make sure each piece works in concert.
  10. 40-Hour Week Burning the midnight oil kills performance. XP teams endeavor to work a fixed number of hours each week and to never work overtime two weeks in a row.
  11. Onsite Customer Developers aren't allowed to make business decisions, so having a real, live customer or user on the team, available full-time to answer questions speeds the process. I think this dovetails nicely with a well developed discipline of product management.
  12. Coding Standards Having a coding standard prevents the team from being distracted by silly arguments and supports the pair programming and collective code ownership principals.

Some are put off by the religious fervor that XP devotees have. I put that down to excitement at discovering something they like and that works for them. From my perspective, XP is about big-scale programming. I think it would be difficult to do in a start-up and maybe not as useful where typically one visionary is creating the pilot. I'm intrigued though. If I were managing a development team again, I'd probably give it a try.