Extreme programming, or XP—not to be confused with XP from Windows XP, where XP stands for eXPerience—has gained in popularity over the past few years as an accepted development methodology. It probably doesn’t do justice to talk about XP in an appendix because it is a rather involved software development practice. However, I will touch on what XP is and what a case study at Microsoft revealed about the practice. I include links throughout this appendix and references at the end for further reading.
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.
The two most popular XP practices that seem to be adopted by various teams at Microsoft are test-driven development (TDD) and refactoring. The developers I have spoken to who have used the TDD technique swear they would never go back to the traditional “write first, test later” process. They say that by writing the tests up front, they have fewer bugs in their code when they are close to shipping. The only difference I see that they do from what is prescribed by Kent Beck is that the Microsoft testers write their tests at the same time they write their production code, not before they write their production code.
Refactoring is the process of rewriting written material to improve its readability or structure, with the explicit purpose of keeping its meaning or behavior.
In software engineering, the term refactoring is often used to describe modifying source code without changing its external behavior. It is sometimes informally referred to as “cleaning it up.” Refactoring is often practiced as part of the software development cycle: Developers alternate between adding new tests and functionality and refactoring the code to improve its internal consistency and clarity. Testing ensures that refactoring does not change the behavior of the code.
Refactoring is the part of code maintenance that doesn’t fix bugs or add new functionality. Rather, it is designed to improve the understandability of the code or change its structure and design to make it easier for human maintenance in the future. In particular, adding new behavior to a program might be difficult with the program’s given structure, so a developer might refactor it first to make it easy and then add the new behavior.
Refactoring has been around Microsoft for years. I know when I was in the NT group in 1991, developers were refactoring and optimizing their code as needed or as a general practice, and this was in the early days of the product when the code was just being written.
The following is an explanation taken from http://encyclopedia.laborlawtalk.com/Extreme_programming:
Test-driven development (TDD) is a programming technique heavily emphasized in extreme programming. Essentially, the technique involves writing your tests first [and] then implementing the code to make them pass. The goal of TDD is to achieve rapid feedback and implement the “illustrate the main line” approach to constructing a program.
Write the test—It first begins with writing a test. In order to write a test, the specification and requirements must be clearly understood.
Write the code—The next step is to make the test pass by writing the code. This step forces the programmer to take the perspective of a client by seeing the code through its interfaces. This is the design-driven part of TDD.
Run the automated tests—The next step is to run the automated test cases and observe if they pass or fail. If they pass, the programmer can be guaranteed that the code meets the test cases written. If there are failures, the code did not meet the test cases.
Refactor—The final step is the refactoring step, and any code clean-up necessary will occur here. The test cases are then re-run and observed.
Repeat—The cycle will then repeat itself and start with either adding additional functionality or fixing any errors.
You can go about using TDD in various ways. The most common one is based on KISS (keep it simple, stupid) or YAGNI (you ain’t gonna need it). This style focuses on writing code any way necessary to pass the tests. Design and proper principles are cast aside in the name of simplicity and speed. Therefore, you can violate any rule as long as the tests will pass. This can be unsettling for many at first, but it allows the programmer to focus only on what is important. However, the programmer pays a higher price in the refactoring step of the cycle because the code must be cleaned up to a reasonable level at this point before the cycle can restart.
To see how a typical extreme programming scenario might look from a programmer’s view, the following is a generic procedure taken from www.linuxdevcenter.com/pub/a/linux/2001/05/04/xp_intro.html. (By the way, this is the only reference to Linux in this book, so the subtle hint here is that extreme programming seems to serve the open source community best at this time.)
The customer lists the features that the software must provide.
Programmers break the features into standalone tasks and estimate the work needed to complete each task.
The customer chooses the most important tasks that can be completed by the next release.
Programmers choose tasks, and work in pairs.
Programmers write unit tests.
Programmers add features to pass unit tests.
Programmers fix features/tests as necessary, until all tests pass.
Programmers integrate code.
Programmers produce a released version.
[The] customer runs acceptance tests.
[The] version goes into production.
Programmers update their estimates based on the amount of work they’ve done in the release cycle.
This is just an example, but it should give you an idea of the workflow if you are a developer in an extreme programming environment.
Before adopting something, especially a new development process, Microsoft forms a task force or focus group to do some research. Following are some results of a case study done by some project managers at Microsoft in 2003. This is just one case study of the extreme programming practices to see if it would be viable for Microsoft to adopt, so take it for what it is worth. After studying a couple of companies that have used the extreme programming methods to ship a couple of products (whose names must be withheld for confidentiality reasons), this is what the task force came up with for recommendations:
Overall opinion on extreme programming methods success was mixed.
Positives in using the extreme programming methods as described by Beck:
Able to quickly respond to business needs.
Test-driven design was mandated company-wide because of successful results.
Continuous integration testing was very valuable.
Simplicity noticeable when a request came in the middle of the development and was easily implemented in two weeks. The revenue generated from the change would pay for the entire development effort.
Trust with management increased because of openness.
Negatives in using the extreme programming methods as described by Beck:
Did not see a noticeable quality improvement—possibly because of the lack of unit tests.
Difficult to address “plumbing” and future releases.
Barriers that were there:
Overall, there was little resistance.
Alignment with business drivers was critical.
Management resistance to pair programming.
Onsite customer was not practical.
The primary barrier was the name extreme. Agile development was a better term.
General observations:
XP can revolutionize the ability to respond to changes in the business climate.
XP increases software development predictability.
Value can be derived from partial implementation, but...
The whole is greater than the sum of the parts.
Final observation:
XP depends on solid programming frameworks and mature technologies.
In general, extreme programming is believed to be useful for small- to medium-sized teams with fewer than 12 persons. It seems that if the development group is large or greater than 20–30 people, the quality of the code will suffer unless you have “extremely” good tools and processes that monitor all the extreme programming methods and you adopt all or none. The general consensus is that extreme programming is good for some projects and not so good for others. It depends on the project you are working on and the culture your developers live in, so choose wisely.
“eXtreme Programming.” Overview and case studies by Microsoft Architect Council. Sept 2003.
“Extreme Programming.” Microsoft document by Ian Lewis, development lead.
Reis, Luis Miguel. “Test Engineering: Microsoft Solutions Framework vs. Extreme Programming.”
http://berlin.inesc.pt/cadeiras/pfsi/PFSI2003/SEMINARIO/pdfs/testes-luis-reis.pdf.Beck, Kent. Extreme Programming Explained—Embrace Change. Addison-Wesley: Boston, 2000.
“XProgramming Software Downloads.”
http://xprogramming.com/software.htm.