What Is Extreme Programming?

At its core, extreme programming is a software development discipline. What makes it unique is that it evolved from careful scrutiny of existing methodologies and practices, determining their flaws and then correcting them. The extreme in extreme programming comes from these corrections, because they are not subtle. The basic idea is that if something is good, don't just do it more often, do it all the time. Extreme programming is based on a set of principles that change the way you write every line of code.

There are four basic principles of extreme programming:

• Communication
• Simplicity
• Feedback
• Courage

Communication

Communication is critical in all software development, so extreme programming takes several basic steps to insure good communication. First, the teams are small, with fewer than 10 developers--ideally, five to six. Information flows freely and with little distortion in groups of this size. Second, the daily "stand up" meetings not only encourage communication, but actually force it. The daily "stand up" meeting is exactly as it sounds: It occurs every day at the same time, preferably in the morning, and everybody stands in a circle. Each team member then answers three questions:

• What did you do yesterday?
• What are you going to do today?
• What problems or issues did you run into?

The reason for standing is simple: It not only keeps meeting attendees alert, but also keeps whoever is answering the three questions focused on the topic. Note that the third question is just a statement of the problems or issues that you ran into. Stand-up is not the time to problem solve, but rather a starting point to record problems and determine whether they can be solved by the person working on them currently or they need additional help.

The third way extreme programming promotes good communication is by creating a role within the process for the customer. In most other methodologies, the role of the customer is played by some sort of rather lengthy requirements document. This works; however, it is difficult to ask questions of a document. Instead of lengthy requirements, extreme programming relies on a customer who writes lightweight requirements called stories, is always available to answer questions, attends stand-ups, and writes all the test cases for the system.

The fourth, and probably most controversial, way extreme programming promotes communication is through paired programming. Most software development methodologies recognize peer review of code as being critical. However, most of the time, that either doesn't happen often enough or happens too late in the cycle for any substantive changes to be made. So if peer review is good, it should be done all the time. Paired programming is two people working together on one computer. In other words, paired programming is constant peer review. Good programming pairs talk constantly the whole time they are working together. They discuss different ways of doing things and keep each other from making mistakes or taking shortcuts. Paired programming done right produces very high-quality code and ensures that at least two people understand every part of the system. I will talk more about paired programming under the section on courage.

Simplicity

Simple things work better than complicated things, so extreme programming always chooses the simplest solution. Let's take a look at the basic flow of how a new requirement gets added to the system. First, the customer comes up with the idea for some new piece of functionality and then writes a story card. Story cards are written by hand on 4x6 cards. The customer then writes of series of tests for the new requirement. The programming team breaks down a story into one or more tasks, which are also written on cards, each of which represent a few days of effort. The programming team does all of its work in 2-4 week cycles called iterations, so for each iteration the customer selects which stories will be worked on. When the iteration begins, the programmers write the code and tests for each of the tasks. When all the tests pass for a story, it is considered complete.

I'm sure you have noticed by now that extreme programming relies on cards rather than documents. The reason for this is that cards are more dynamic than documents. Cards take only seconds to create, you can draw little diagrams on them, and you just throw them away if you don't like them. People grow attached to things that they spend time on. Imagine a customer who spends several months perfecting the greatest requirements document ever written vs. a customer who spend a few hours writing up some story cards. Both customers come to a meeting to have their requirements broken down into tasks, and it turns out that half of each of their requirements can't be implemented because of a technical limitation. While both customers will be disappointed at first, there is a pretty good chance that the customer who spent months preparing his documents is going to try to force a less than optimal solution. And even if he doesn't, he will face many hours of updating his documents to reflect what will be done. On the other hand, the customer that used story cards simply files away the stories that couldn't be completed and moves on.

Not only does extreme programming advocate simple solutions, it is itself a simple solution. The first, and in my opinion still the best, extreme programming book is Extreme Programming Explained: Embrace Change by Kent Beck. The book, including an extensive bibliography, is under 200 pages. I've read books on just writing use cases that were twice as long.

Feedback

Although feedback is generally thought of as just a type of communication, it is given its own category in extreme programming, and it happens on many different levels. Since the customer is always available, programmers can give feedback at any time on what is good or bad about their stories. In paired programming, programmers are constantly giving each other feedback on their code. At the end of each iteration, the estimate of how long a task was expected to take is compared with how long it actually took. This information is then used to predict how long similar tasks will take in future iterations. However, the most often overlooked type of feedback is on the code itself. Extreme programming is based on test-first programming. In the case of Java programming, test-first programming almost always involves the use of JUnit or one of its derivatives. JUnit is a simple mechanism for creating automated unit tests for your code. So you write a series of tests, and then you write your code. Once all the tests pass for your task, you are done with the task. For more information on test-first programming, see my article "JUnit: An Automated Test Runner for Java." By using automated testing, you are constantly getting feedback on whether your code works or not.

Extreme programming also advocates frequent integration testing. This means that every time you complete a task, and even when you are still working on it if it is a long one, you integrate all your code. Integration involves checking all your code in to source control, then pulling the entire system from source control to a clean machine where it is built and where every test that exists for the systems is run. If they all pass, you are done; if they don't, you either have to fix the code that breaks a test or back out your integration. Again the best mechanism for doing this in Java is JUnit. Also note again the recurring theme of "if doing it sometimes is good (in this case, testing) then doing it all the time is best."

Courage

Extreme programming both requires courage and gives you courage. Let me explain. First, you need courage in order to convert to extreme programming. It is going to take courage to explain to management why you have two programmers on a single task and how this will be more productive in the long run than just a single programmer working on a task because the quality of the code will be higher and the knowledge base of the team will be more collective. It will also take courage to explain to them that you are replacing their thick binders of product requirements with a bulletin board covered with note cards. However, extreme programming will also give you courage. When things start changing, and they always do, you have a lightweight, nimble process that allows for change. You can add or remove functionality continuously, because your tests are all automated and you don't have to worry about what will this break if you add something.

Benefits

Besides being lightweight and adaptable, extreme programming has several other benefits. For programmers, extreme programming is empowering. It enables programmers to determine how stories map into tasks as well as to give estimates on how long things will take. In addition, the tasks for iteration are not assigned to programmers; rather, programmers choose the tasks they would like to work on. Also, programmers get to work on lots of little tasks and don't get bogged down in schedules that list every task they will be working on for the next six months. Pair programming is also great way to hone your existing skills or pick up new ones. And because of the automated testing in extreme programming, you are free to do lots of refactoring of the code base to introduce design patterns. Most software systems start out organized and slowly degrade into chaos over time. With extreme programming, because of your ability to refactor and add design patterns, the system order can be prevented from degrading and in most cases can even be improved over time. For more information on refactoring and design patterns, please see the following articles: "Java Journal: Refactoring" and "Java Journal: Design Patterns."

For the customers, extreme programming lets them do their favorite thing--change their minds. It also ensures that the programming team is always working on the features that are most important to them first. One amazing benefit to both management and customers is that, since integration testing is always up to date, the system is always in a stable state. So the system is kept in a near shippable state at all times. Management should consider the extreme in extreme programming to stand for extremely conservative. After all, risks are lowered in two ways. First, every part of the system has been worked on by at least two people and in most cases probably by everyone, so there are no dirty little secrets waiting to pop out at the last minute. This also means that after the initial development, you can assign people out to other projects instead of having to keep them all available in case the part of the system that they are an "expert" in has problems. This is also very useful in case somebody gets hit by a bus. It has been my experience that the person most likely to get hit by a bus is the person who not only wrote the most critical part of the system, but also wrote the most convoluted, spaghetti code in the whole system. The second way risk is mitigated is that the system is well-tested and can be proven to work. Another benefit--and from the customer's standpoint, probably the most important benefit--is that systems developed using extreme programming make customers happy.

The Downside

Extreme programming does have a few downsides. It doesn't scale well. If you have too many people on a team, your communication will break down, stand-up meetings will go on too long, and your odds of having problems with people who don't like to pair with each other go up exponentially. Too few people, and you have problems with what to do with the person who doesn't have a partner for pairing. That said, don't let the size of an extreme programming team fool you. I have seen a small extreme programming team pull off projects that I thought would have taken two or three times as many people. Another thing to consider is that many of the most talented programmers I have worked with over the years keep rather odd or irregular hours or even work remotely. For these developers, you have to be flexible. Don't try to force them into showing up for an 8:00 a.m. stand-up five days a week. They will resent the whole process, and it will fail. Extreme programming is geared toward highly dynamic projects with high risk, so it is probably not suitable for lower risk projects with well-defined, static requirements. I'm not sure if I've ever heard of a project of the latter type, but just in case one exists, it's probably not a good extreme programming candidate.

Conclusion

Extreme programming works. It is not just a collection of ideas that some academic scribbled down to sell books. How do I know this? Well, as you probably already know if you are a regular reader of "Java Journal," I have been on an extreme programming team for over two years. The last two years have been simultaneously the most challenging, productive, and rewarding two years of my career. All aspects of extreme programming are based on its four basic principles of communication, simplicity, feedback, and courage. Extreme programming excels where other methodologies fail in that it benefits the programmers, customers, and management equally. Programmers are empowered to do their own estimates, pick their own tasks, and build their skills. Customers get exactly what they ask for and the ability to change their minds and reprioritize as they go. Management gets a high-quality, well-tested system and--best of all--a happy customer. However, extreme programming is not for everyone; it works best with small teams of programmers on highly dynamic, risky projects. It can be hard to sell to management because of the paired programming aspect. In fact, I think the whole thing would have gained better acceptance with management if it had been called "Double Conservative, Ultra Tested, Customer Driven Programming," but then again, with a name like that I probably would never have tried it.

Author's Note: You will see some literature that refers to extreme programming as simply XP; however, this term has fallen out of favor since the release of Windows XP. For more information on extreme programming, see the official site. Or, if you have specific questions for me, feel free to drop me an email or, better yet, post to the forums here at MC Press Online, and I'll do my best to answer them.

Michael J. Floyd is an extreme programmer and the Software Engineering Technical Lead for DivXNetworks. He is also a consultant for San Diego State University and can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..