![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
CEOs have faced enormous pressure over the last decade to produce steadily rising earnings. We have seen their response in such initiatives as corporate downsizing, outsourcing, re engineering, enterprise resource planning (ERP), and others. This attack on inefficiency has allowed many of the organizations in the S&P 500 to maintain double-digit earnings growth for several years during the latter part of the 1990s. But something wicked this way comes.
In his book Leading the Revolution (see Resources), Gary Hamel asserts that several indicators demonstrate that not much fat is left to cut in traditional business models. We must find alternatives for fueling continued earnings growth. He suggests the only thing that will allow companies to continue generating growth is radical innovation. We think this is especially true in the area of software development.
If you use standard software development approaches, even if you are developing on the Java platform, prepare yourself for disappointment. As Figure 1 shows, recent studies indicate that you can expect half of your projects to be late and one third of them to be over budget. This projection is only slightly better than the study done in 1979 by the Government Accounting Office.
Figure 1. Software project success and failure, then and now
If we are to improve these numbers significantly, we need radically innovative ways to develop software. Two primary factors influenced existing methodologies:
- Fear of failure
- A misunderstanding of the nature of software
Nobody plans to fail. The irony is that approaches created to minimize failure are failing. Misunderstanding software is the root of the problem. Fear really is just a symptom. Existing methodologies were created by smart people who meant well but who forgot the "soft" in software. They assumed that making software is like building a bridge. So they borrowed best practices from various engineering disciplines that apply very well to "hard" things, like bridges. The result is unresponsive development practices based on a Big Design Up-Front (BDUF) mentality, and brittle software that people can't use.
Recently, the movement has been away from so-called "heavyweight" methodologies to "lightweight" or "agile" ones such as Crystal Methods, Adaptive Software Development, and (currently the most popular) XP. All of these processes embrace the reality that people work with people to develop software. Successful software processes must maximize people's strengths and minimize their weaknesses, as both unarguably exist. In our opinion, XP does the best job of addressing all the complementary forces that affect the people involved.
XP represents the single biggest opportunity this decade to bring radical innovation to the process of software development. As Peopleware author Tom DeMarco puts it, "XP is the most important movement in our field today. I predict that it will be as essential to the present generation as the SEI and its Capability Maturity Model were to the last."
XP prescribes a core set of values and practices that allow software developers to do what they do best: write code. XP eliminates the unnecessary artifacts of most heavyweight processes that distract from that goal by slowing down and draining the development staff (for example, Gantt charts, status reports, and multi-volume requirements documents). We recognize that something called "Extreme Programming" might be tough to sell to your management as a serious development process, but if your company is in the software business, it behooves you to help management see past the name to the competitive advantage XP can provide.
Kent Beck outlined the core values of XP in his book Extreme Programming Explained: Embrace Change (see Resources). We summarize them this way:
- Communication. Problems with projects often can be traced back to somebody not talking to somebody else about something important at some point. XP makes it almost impossible not to communicate.
- Simplicity. XP proposes that you always do the simplest thing that could possibly work with regard to process and writing code. The way Beck puts it, "XP is making a bet. It is betting that it is better to do a simple thing today...than to do a more complicated thing today that may never be used anyway."
- Feedback. Concrete feedback early and often from the customer, from the team, and from real end users gives you more opportunity to steer your efforts. Feedback keeps you on the road and out of the ditch.
- Courage. Courage exists within the context of the other three values. They all support each other. It takes courage to trust that concrete feedback along the way is better than trying to know everything up front. It takes courage to talk to others on the team when that might expose some of your own ignorance. It takes courage to keep the system simple, deferring tomorrow's decisions until tomorrow. And without a simple system, constant communication to spread knowledge, and feedback to steer with, it's tough to be brave.
The practices of XP translate these values into the things you should do every day as a developer. There isn't much new here. The XP practices have been recognized by the industry for years as "best practices." In fact, the word "extreme" in XP derives from two things:
- XP takes proven industry best practices and turns the knobs up to 10.
- XP combines those practices in a way that produces something greater than the sum of the parts.
What does this look like? Code reviews are good, so do them all the time by writing code in pairs. Testing is good, so do it all the time by writing tests before you write code. Documentation rarely stays in sync with the code, so do only the minimum necessary and depend on clearly written code and tests for the rest. XP doesn't guarantee that people will do the right thing all the time, but it allows them to. It combines these "extreme" practices in a mutually supportive way that produces significant increases in speed and efficiency.
The twelve practices of XP (shown in Figure 2) define it as a discipline. Let's take a closer look at each to get a better understanding of what it means to "do XP."
Figure 2. Twelve practices of XP
Some people like to criticize XP as glorified hacking, just a bunch of cowboys cobbling together a system without any discipline. Wrong. XP is one of the few methodologies out there that recognizes that you can't know everything when you start. Both the customers and the developers will learn things as the project progresses. Only methodologies that encourage and embrace such change will be effective. Status quo methodologies ignore change. XP listens. The way it listens is through the "planning game," a concept coined by Kent Beck.
The main idea behind this practice is to make a rough plan quickly and refine it as things become clearer. The artifacts of the planning game are: a stack of index cards, each containing a customer story, which will drive the project's iterations; and a rough plan for the next release or two, as described in Planning Extreme Programming (see Resources) by Kent Beck and Martin Fowler. The critical factor that lets this style of planning work is letting the customer make business decisions and allowing the development team to make technical ones. Without that, the whole process falls apart.
The development team determines:
- Estimates of how long it will take to develop a story
- Cost implications of using various technology options
- Team organization
- The "risk" of each story
- Order of story development within an iteration (doing risky items first can mitigate risk)
The customer determines:
- Scope (the stories for a release and the stories for each iteration)
- Release dates
- Priority (which features get developed first, based on business value)
Planning happens often. This provides frequent opportunity for either the customer or the developers to adjust the plan as they learn new things.
In XP, pairs of developers write all production code. This approach may sound inefficient. As Martin Fowler says, "When people say that pair programming reduces productivity, I answer, 'that would be true if the most time-consuming part of programming was typing.'" In fact, pair programming provides many benefits, economic and otherwise:
- All design decisions involve at least two brains.
- At least two people are familiar with every part of the system.
- There is less chance of both people neglecting tests or other tasks.
- Changing pairs spreads knowledge throughout the team.
- Code is always being reviewed by at least one person.
Research also is showing that programming in pairs is actually more efficient than programming alone (see The Costs and Benefits of Pair Programming by Alistair Cockburn and Laurie Williams in Resources for more details).
There are two kinds of testing in XP:
- Unit testing
- Acceptance testing
Developers write the unit tests as they write code. The customer writes acceptance tests after they define stories. Unit tests tell developers whether the system "works" at any point in time. Acceptance tests tell the team whether the system does what users want it to do.
Assuming the team is using an object-oriented language like Java, developers write unit tests for every method that could possibly break, before they write the code for those methods. Then they write just enough code to get the test to pass. People sometimes find this a little weird. The point is simple. Writing tests first gives you:
- The most complete set of tests possible
- The simplest code that could possibly work
- A clear vision of the intent of the code
A developer cannot check code into the source code repository until all the unit tests pass. Unit tests give developers confidence that their code works. It leaves a trail for other developers to understand the original developer's intent (in fact, it's the best documentation we've ever seen). Unit tests also give developers courage to refactor the code, because a test failure tells the developer immediately if something's broken. Unit tests should be automated and give a clear pass/fail result. xUnit frameworks (see Resources) do all this and more, so most XP teams use them.
Customers are responsible for making sure each story has acceptance tests to validate it. The customer can write the tests himself, recruit other members of his organization (for example, QA people or business analysts) to write them, or combine the two approaches. The tests tell them if the system has the features it is supposed to have, and that they work correctly. Ideally, the customer will have the acceptance tests for the stories in an iteration written before that iteration is finished. Acceptance tests should be automated and run frequently to ensure developers are not breaking any existing features as they implement new ones. Typically, customers will need some help from the development team to write acceptance tests. On one project, we developed a reusable automated acceptance test framework that lets the customer enter inputs and expected outputs in a simple editor. The framework converts the input to an XML file, runs the tests in the file, and spits out "pass" or "fail" for each. Customers love it.
Not all of the acceptance tests have to pass all the time. The point is that acceptance tests help customers gauge how "done" the project is. They also allow customers to make informed decisions about whether or not something is ready for release.
Refactoring is the technique of improving code without changing functionality. An XP team refactors mercilessly.
Two key opportunities exist for developers to refactor: before and after implementing a feature. Developers try to determine if changing existing code would make implementing the new feature easier. They look at the code they just wrote to see if there is any way to simplify it. For example, if they see an opportunity for abstraction, they refactor to remove duplicate code from concrete implementations.
XP says you should write the simplest code that could possibly work, but it also says you'll learn along the way. Refactoring lets you incorporate that learning into your code without breaking the tests. It keeps your code clean. That means it will survive longer, introduce fewer problems for future developers, and guide them in the right direction.
XP's detractors claim that the process neglects design. This isn't true. The problem is that heavyweight approaches say you should do all but the most trivial design tasks up front. This is like taking a static picture of the horizon, staying still, and trying to draw a perfect map of how to get there. XP says design should not be done all at once, up front, under a delusion that things won't change. XP considers design so important that it should be a constant affair. We always try to use the simplest design that could possibly work at any point, changing it as we go to reflect emerging reality.
What is the simplest design that could possibly work? It is the design that (thanks to Kent Beck for this list):
- Runs all the tests
- Contains no duplicate code
- States the programmers' intent for all code clearly
- Contains the fewest possible classes and methods
Requiring a simple design doesn't imply that all designs will be small or that they will be trivial. They just have to be as simple as possible and still work. Don't include extra features that aren't being used. We call such things YAGNI, which stands for "You Aren't Going to Need It." Don't let YAGNI destroy your chances for success.
Collective code ownership
Any person on the team should have the authority to make changes to the code to improve it. Everybody owns all the code, meaning everybody is responsible for it. This technique allows people to make necessary changes to a piece of code without going through the bottleneck of an individual code owner. The fact that everybody is responsible negates the chaos that ensues from no code ownership.
Saying that everybody owns all the code isn't the same as saying that nobody owns it. When nobody owns code, people can wreak havoc anywhere they want and bear no responsibility. XP says, "You break it, you fix it." We have unit tests that must run before and after each integration. If you break something, it's your responsibility to fix it, no matter where it is in the code. This requires extreme discipline. Maybe that's another reason for having "extreme" in the name.
Frequent code integration helps you to avoid integration nightmares. XP teams integrate their code several times a day, after they get all the unit tests for the system to run.
Traditional approaches tend to work like this: code a lot, do a big-bang integration, then spend a significant amount of time fixing the problems. This yo-yo style really slows a project down. Big-bang integrations dump a load of problems on the team all at once, and those problems often have hundreds of possible causes.
When you integrate frequently, the cause of failure for any particular integration is more obvious (the tests ran before, so the new stuff must be to blame). This way, when you encounter problems, there is a rather limited set of possible causes. Fixing is easier, takes less time, and keeps the team moving at maximum speed.
To function optimally, an XP team needs to have a customer available on site to clarify stories and to make critical business decisions. Developers aren't allowed to do that alone. Having a customer available eliminates bottlenecks that can arise when developers have to wait for decisions.
XP does not pretend that a story card is all the direction a developer needs to deliver the necessary code. The story is a commitment to a later conversation between the customer and the developer to flesh out the details. The idea is that communicating face to face minimizes the chances of misunderstanding, unlike writing all the requirements down in a static document.
We have found that having the customer on site is the best possible situation, but it's not the only scenario that will work. The bottom line is that the customer must be available whenever needed to answer questions and to provide direction for the team based on business value. If that can happen without the customer being on site with the team full-time, great. Physical presence with the team makes this much easier, however, thus the recommendation.
Releases should be as small as possible while still delivering enough business value to make them worthwhile.
Release the system as soon as it makes sense to do so. This provides value to the customer as early as possible (remember that money today is worth more than money tomorrow). Small releases also will provide concrete feedback to developers on what meets customer needs and what doesn't. The team then can include these lessons in its planning for the next release.
Kent Beck says that he wants to be "...fresh and eager every morning, and tired and satisfied every night." The 40-hour work week lets you do that. The exact number of hours isn't important - the principle is. Burning the oil for long periods kills performance. Tired developers make more mistakes, which will slow you down more in the long run than keeping a "normal" schedule will.
Even if developers could function well for longer periods, it doesn't mean they should. Eventually, they'll get tired of it and leave their jobs, or have non-work problems that will impact their performance. You mess with people's lives, you suffer the consequences. Overtime isn't the answer to a project's problem. In fact, it's a symptom of a larger problem. If you need a death march, you screwed up.
Having a coding standard does two things:
- It keeps the team from being distracted by stupid arguments about things that don't matter as much as going at maximum speed.
- It supports the other practices.
Without coding standards, it is harder to refactor code, harder to switch pairs as often as you should, and harder to go fast. The goal should be that no one on the team can recognize who wrote which piece of code. Agree on a standard as a team, then stick to it. The goal isn't to have an exhaustive list of rules, but to provide guidelines that will make sure your code communicates clearly. Your coding standard should begin simply, then evolve over time based on team experience. Don't spend too much time on it up front. Create the simplest standard that could possibly work, then get moving.
What does an architecture do? It provides a picture of the various components of a system and how they interact -- a sort of map that lets developers see where new pieces will fit.
The system metaphor in XP is analogous to what most methodologies call architecture. The metaphor gives the team a consistent picture they can use to describe the way the existing system works, where new parts fit, and what form they should take.
It is important to remember that having everyone understand how the system fits together is critical, not a beautiful metaphor. Sometimes, you just can't come up with a good one. It's great when you can.
The whole is greater than the sum of the parts. You can implement single practices, or a small subset, and get great benefits over not using any. But you only get the maximum benefit if you implement all of them, because their power comes from their interaction.
Do XP by the book at first as a benchmark. Once you understand how the practices interact, you will have the knowledge you need to adapt them to your context. Remember that "doing XP" is not the goal, it is a means to an end. The goal is developing superior software quickly. If your process mutates in a manner that disqualifies you from saying you are doing XP, yet your results are blowing the doors off your competitors, you have succeeded.
To be blunt, XP (or any other agile methodology) doesn't matter at all. The results it can produce are what count. If an agile approach like XP can help you deliver better software faster and without as much pain, then it is worth considering.
Remember those daunting numbers we mentioned at the start of this article? We believe that using XP to develop object-oriented software has the best chance of changing them for the better. Our experience so far has confirmed that belief.
- Read about the economics of pair programming in The Costs and Benefits of Pair Programming by Alistair Cockburn and Laurie Williams (XP2000 submission, 2000).
- Download xUnit testing tools.
- If you want to learn more about XP, be sure to pick up a copy of the books referenced in this article:
- Planning Extreme Programming by Kent Beck and Martin Fowler (Addison-Wesley, 2000)
- Extreme Programming Explained: Embrace Change by Kent Beck (Addison-Wesley, 1999)
- Leading the Revolution by Gary Hamel (Harvard Business School, 2000)
- Jeff Canna's article on unit and functional testing (developerWorks, March 2001) puts the XP philosophy to the test.
Roy W. Miller is a Software Developer at RoleModel Software, Inc. While at RoleModel, Roy has developed a Java/XML-based automated acceptance testing framework and has prototyped several applications for the TINI Java platform from Dallas Semiconductor. Prior to joining RoleModel, he spent six years with Andersen Consulting (now Accenture) using their proprietary heavyweight Business Integration Methodology (BIM) and variations thereof. Since joining RoleModel, he has gained experience with XP and local adaptations of that approach. Roy has co-authored a book in the Addison-Wesley XP Series (XP Applied, scheduled for publication in October 2001), and will be a featured panelist at the XP2001 "Business of XP" fishbowl. Contact Roy at rmiller@rolemodelsoft.com.
Christopher T. Collins is a Senior Software Developer at RoleModel Software, Inc. While at RoleModel, Chris has taken part in an XP project that has run for almost two years, developed an embedded Java application for a new Motorola cell phone platform, and ported JUnit to run on Sun's J2ME platform. Before joining RoleModel, he spent five years developing software for several organizations using many different languages, most recently for U.S. Department of Defense applications. He has experience using and adapting several different development methodologies, both agile and heavyweight, including RUP and XP. Chris has an M.S. in Computer Science and Software Engineering from the University of West Florida, and currently teaches a Java programming course at North Carolina State University. He has been an invited speaker on XP at Duke University, and will be presenting a paper on process adaptation at XP2001. Contact Chris at ccollins@rolemodelsoft.com.
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
