Extreme programming

Extreme programming (XP) is a different approach to software development; it’s been in use with great success by big companies all over the world for the last ten years. The methodology is designed to deliver the customer needs and be flexible enough to adapt to changes in any phase of the life cycle. XP is built on four main concepts; simplicity, developers are encouraged to build the simplest solution that gets the job done. Communication, team members communicate with the customer and each other early and often. Feedback, the code is tested as it’s developed so developers can fix issues as early as possible. Courage, with these concepts in place its easy for developers to change their design and code to react to changing requirements. 

XP practices: 

1. The Planning Game: The Business team comes up with a list of features for the system. Each feature is written out as a User Story, which gives the feature a name, and describes what is required. The Development team estimates how much of the user stories can be implemented in a given time interval (the iteration). Business team decides which stories to implement in what order.
2. Start with the smallest useful feature set. Release early and often, adding a few features each time.
3. Always use the simplest possible design that gets the job done. All you need to do is to meet the requirements as they are right now.
4. Before programmers add a feature, they write a test for it. When the suite runs, the job is done. Unit Tests are automated tests written by the developers to test functionality as they write it. The customer specifies the acceptance tests to test that the overall system is functioning as specified. When all the acceptance tests pass for a given user story, that story is considered complete.
5. Refactor out any duplicate code generated in a coding session. You can do this with confidence that you didn’t break anything because you have the tests.
6. Pair Programming: two programmers sitting at one machine write Code. Essentially, all code is reviewed as it is written.
7. Collective Code Ownership: No single person “owns” a module. A developer is expected to be able to work on any part of the codebase at any time.
8. Continuous Integration: All changes are integrated into the codebase at least daily. The tests have to run 100% both before and after integration.
9. Programmers go home on time. In crunch mode, up to one week of overtime is allowed. But multiple consecutive weeks of overtime are treated as a sign that something is very wrong with the process.
10. Development team has continuous access to a real live customer, that is, someone who will actually be using the system.
11. Everyone codes to the same standards. Ideally, you shouldn’t be able to tell by looking at a piece of code which developer on the team has touched it.

Of coarse each company and each project should only implement the practices that make sense to them. Even if you don’t follow all the XP rules, you can still take advantage of some of these practices to improve your development methodology considerably. I’ll talk about the practices that I think are essential in future posts.