| Extreme programming is an agile software development methodology formulated by Kent Beck, Ward Cunningham, and Ron Jeffries. Kent Beck wrote the first book on the topic, Extreme Programming Explained, in 2000. As Beck says (taken from Extreme Programming in Practice, by Newkirk and Martin): Extreme programming, familiarly known as XP, is a discipline of business and software development that focuses both parties on common, reachable goals. XP teams produce quality software at a sustainable pace. The practices that make up "book" XP are chosen for their dependence on human creativity and acceptance of human frailty. Although XP is often presented as a list of practices, XP is not a finish line. You don't get better and better grades at doing XP until you finally receive the coveted gold star. XP is a starting line. It asks the question, "How little can we do and still build great software?" The beginning of the answer is that, if we want to leave software development uncluttered, we must be prepared to completely embrace the few practices we adopt. Half measures leave problems unsolved to be addressed by further half measures. Eventually you are surrounded by so many half measures that you can no longer see that the heart of the value programmers create comes from programming. I gathered the following list of the fundamental characteristics or practices of the extreme programming method from the sources listed at the end of this appendix: Incremental and iterative developments In contrast to traditional development practices, detailed specifications are not written at the beginning of the project. Do small improvements after small improvements. Start with a rough plan of what your features and product should do, and then start writing code. As development progresses, modify and shape the original plan as necessary. Continuous, often repeated automated unit test, regression testing Every feature of the product should be testable with a comprehensive set of tests. Luis Miguel Reis has written a good document, "Test Engineering: Microsoft Solutions Framework vs. Extreme Programming" (see link at end of this appendix), that discusses the test methodology of the two practices. In summary, in the extreme programming method, you basically run BVTs all the time, and if the tests run and pass, you're done. What's interesting is that it is recommended that you write the tests before you start coding the features. This seems awkward, but it becomes clearer when you understand the process. Even so, Microsoft's approach has been to write the tests and feature code simultaneously instead of first. To dive into details, see the section on test-driven development (TDD) later in this appendix. Short iterations/small, frequent releases Usually every 1 or 2 weeks, binaries are released to the customer, not just iterations on a project chart. The idea is to put a simple system into production immediately and then release new versions on a short cycle. At the very least, you get better at the most important skill: releasing software. Pair programming Production code is written by two people sharing one keyboard and one mouse. Each member performs the action the other is not currently doing. For example, while one types in unit tests, the other thinks about the class that will satisfy the test. Either person can do the typing. The person who does the typing is known as the driver, whereas the person who guides is known as the navigator. It is often suggested that the two partners switch roles at least every half-hour. This idea seems to be the hardest one to sell to non-XP believers. User interaction in the programming team (onsite customer) A customer representative is attached to the project and should be onsite at all times to evaluate the system, give feedback on new builds, and answer questions. This practice seems to be the most expensive (for the customer at least) but is ideal, if possible. Refactoring Whenever a new feature is added, ask if there is a way to change the existing system to make the feature simpler. If there is, change the existing system. For more details, read the book Refactoring: Improving the Design of Existing Code by Martin Fowler. Shared code ownership Just as the term suggests, everyone owns the code. Although there might be experts in different areas, for the most part, anyone on the team can program in any area. Simplicity At any give time, the "best" design for the software is one that runs all the tests, has no duplicated logic, states every intention important to the programmers, and has the fewest possible classes and methods. Anything extraneous should be tossed, or better yet, not written. This is also known as YAGNI you ain't gonna need it. Choose the simplest possible design that satisfies the existing need. Extreme programmers write code only to meet actual needs at the present time in a project and go to some lengths to reduce complexity and duplication in their code. Organizing the system with a metaphor Use a guiding "story" to describe how the system is supposed to work. This is a replacement for "architecture." It's meant to be readable by both technical and nontechnical people and to give everyone a common set of words to describe parts of the system, as well as an idea of how things basically fit together. Continuous integration All code is integrated and tested on a continuous basis. Sustainable pace Working more than 40 hours a week can be counterproductive. When you're tired, you might not be able to concentrate 100 percent of the time and might make major coding blunders. The idea is to stay rested. The rule is that you can't work a second week of overtime.
Ian Lewis, a development lead in the Xbox team, says it best: Serve short-term interests Work with people's short-term interests to serve your long-term goals. In a way, this is XP in a nutshell. We're constantly being told to do things that serve longterm interests, like writing lengthy specs or creating architectures and base classes. XP asks how we can do things that make us productive in the short term, yet still serve our long-term goals. One thing that XP explicitly abandons is the idea that it's prohibitively expensive to make changes to a system. This quick overview should give you a basic idea of what XP is. I see a lot of companies adopting bits and pieces of the XP methodology and then call themselves an "agile development shop." The companies usually run into a lot of problems when they do this because all of the XP methods work in harmony, and if you take one out, "all bets are off." For example, if you try to do continuous integration and do not have good unit tests or pair-programming, you will probably end up with a bunch of build breaks and unstable code. Even so, Microsoft seems to or was already practicing similar methods to the XP model. Next, I talk about the two that I tend to see the most in the development teams. |
