The Pragmatic Craftsman :: Simplicity from complexity : by Stanley Kubasek ::

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.