The Pragmatic Craftsman         :: Simplicity from complexity :: | About Me |

Extreme Programming has been around for years now. From what I hear, it has been successful. I like the process, but I don't think I could withstand all of the practices on a continual basis. Having to pair program on a continual basis is just a pain (bathroom, personal calls, taking breaks, etc). I think it could be done at times, for instance, fixing a critical issue, but on a day to day basis, I dont' think I would be able to do it.

Here are the practices of XP, taken from Extreme Programming Explained book, which I'm currently reading.

• The Planning Game -- Quickly determine the scope of the next release by combining business priorities and technical estimates. As reality overtakes the plan, update the plan.


• Small releases -- Put a simple system into production quickly, then release new versions on a very short cycle.


• Metaphor -- Guide all development with a simple shared story of how the whole system works.


• Simple design -- The system should be designed as simply as possible at any given moment. Extra complexity is removed as soon as it is discovered.


• Testing -- Programmers continually write unit tests, which must run flawlessly for development to continue. Customers write tests demonstrating that features are finished.


• Refactoring -- Programmers restructure the system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility.


• Pair programming -- All production code is written with two programmers at one machine.


• Collective ownership -- Anyone can change any code anywhere in the system at any time.


• Continuous integration -- Integrate and build the system many times a day, every time a task is completed.


• 40 hour week -- Work no more than 40 hours a week as a rule. Never work overtime a second week in a row.


• On-site customer -- Include a real, live user on the team, available full-time to answer questions.


• Coding standards -- Programmers write all code in accordance with rules emphasizing communication through the code.

Based on these practices, I think a good agile process should have the following practices (from the XP process).

• Small releases. A small release lets you find problems quickly and correct them right away.


• Simple design. There is no point on spending too much time designing for the future; nonetheless, some time should be spent on creating a good design, as a bad one can kill or seriously slow down development. No you cannot really refactor a bad design, you would have to rewrite it.


• Testing and Refactoring. We all say we do it, but I think we should be doing more of it. This is essential.


• Continuous integration. It's critical, as a lot of problems are exposed by integrating.


• 40-hour week. This is very important. I don't know about you, but I'm tired after work. I noticed that when I stay overtime from time to time, I enbug the system. Really. I put a lot more bugs into the system than normal. Plus, programmers have a life (we do).

All in all, XP brought a lot of good practices to the development world. It was, and still is, a disruptive force. And that's a good thing. Whatever your process is, make sure it is agile, and exposes problems early.