Level: Introductory Willy Farrell (willyf@us.ibm.com), e-business Architect, IBM
Mary-Rose Fisher (mrfisher@us.ibm.com), e-business Architect, IBM
01 Jun 2001 In this article Willy Farrell and Mary-Rose Fisher discuss the four values developers bring to a software project: communication, simplicity, feedback, and courage. eXtreme programming is a set of practices that apply those values to create an environment where you can rapidly and accurately develop business applications. The 12 basic practices of eXtreme programming are also discussed.
"Listening, testing, coding, designing. That's all there is to software. Anyone who tells you different is selling something." -- Kent Beck, author of eXtreme Programming.
Communication, or more accurately lack of communication, is the source of almost
all software
problems. The customer didn't communicate a requirement, or the developers didn't
communicate difficulties in providing a feature. If we have forthright, timely communication
between all involved, we can eliminate most of our problems. We can't ignore or punish any honest
communication.
Simplicity. What is the simplest thing that could possibly work? Too often we focus on the most
complex and complicated functions of our software when those are the pieces that are rarely or
ever used. Far better to do a simple thing today, and pay a little tomorrow to change it, than do
a complicated thing today that may never be used anyway. This also ties into our communication
value, because the simpler the system, the less communication will be required.
Feedback tells us how we're doing, and also how we're going to do. We need feedback on a working
system to know if it meets customer requirements. We need feedback to know what will be the
most valuable improvements, enhancements, or additions to the system. And we need feedback to know
when we'll be able to deliver a particular function. How can we know how fast we'll
go if we don't know how fast we've gone?
We also bring courage to developing software. Do we have the courage to try
something new and different to slash the project schedule? Are we courageous enough to do the right
thing, even when facing immense budget and deadline pressures?
Are you courageous? Tired of overly complex projects that lack genuine innovation? Ready to
negotiate rather than be dictated to on budget and time constraints? Willing to really understand
your user's needs and desire? Then jump on board -- get eXtreme!
eXtreme programming explained
eXtreme programming (XP) is a set of practices for software development that apply the values
described above to create an environment conducive to the rapid, accurate development of business
applications. If you've been programming for a while, you might look at the practices
below and think "these aren't new; I've done some of these before." And you'd
be right. The innovation in XP is putting all of the practices together, so they support each
other. The strength of some practices offset the weaknesses in others.
You might be struck by how informal XP seems. But don't be fooled -- while it is informal,
it also requires lots of discipline. You have to follow the XP practices, and that means
all of the XP practices, or you're just not doing XP.
Fundamental principles
Before we get to the practices, though, here are some fundamental principles of XP that are
based on our four values.
- Rapid feedback
- The time between an action and feedback on that action
is crucial. You need to know immediately if something is good or bad.
- Assume simplicity
- It saves loads of time. Treat every problem as if it could be
solved with absolutely ridiculous simplicity. Almost all of the time, it can. And you've saved time
to work on problems that really require complex solutions.
- Incremental change
- Big changes just don't work. There are far too many relationships and interdependencies in even the
smallest business application to think that wholesale changes to architecture or code won't cause
problems. But large-scale changes can be made, over time, with a series of the smallest changes that
make a difference.
- Embrace change and quality work
- Some say that the only constant in the world is change. We must accept, even embrace,
change. But instead of anticipating every possible change that might come, we're much more
effective with a strategy that preserves our options while solving our most pressing problems.
As for quality work, there are two choices: excellent and insanely
excellent. Nothing less will do. All the good programmers we've ever worked with believe in
producing great, quality work.
Listen, test, code, design -- in that order
Now let's structure our development activities around the values and principles already discussed.
The most important activities we perform are:
- Listening
- Testing
- Coding and designing
In that precise order. Why this order? We'll explain a bit later.
Exhortations to simply listen to each other do not work. We must really listen,
and
communicate only what's really necessary, and not the extra fluff we're
used to. Set rules to ensure that real communication is encouraged and extraneous words are
discouraged. They simply waste time.
Automate all testing. It doesn't exist if it can't be measured. Automated testing increases
confidence in the system and inspires confidence in our ability to effect quality changes. We need
two types of tests for our two audiences: unit tests for programmers, and acceptance
(or functional) tests for customers.
The one artifact that development absolutely cannot live without is the
actual, almighty code we produce. Our code communicates intent, algorithms, and structure. It needs to be done clearly and concisely.
If the code is the ultimate deliverable, the design becomes critical. We must create a
structure that organizes the logic in the system. Just because logic in one portion requires
modification should not inherently mean another portion of logic must follow. Placing logic near
the data on which it operates allows extension of the system with changes in only one place. The
design must have a context in which good design is created and bad design is fixed and everybody
involved in the project understands the labels.
Now, what about this odd order? In XP, development goes something like this: We listen to
what needs to be done. Then we write tests that, if passed, would prove that we delivered
what was needed. Next, we write the code that will pass those tests. Finally, we tweak and adjust
the design of that code to make it simpler and more effective, while still passing the tests.
Sounds outrageous, right? It's eXtreme!
 |
Twelve practices of XP
- The planning game
- Small releases
- Metaphor for shared mental model
- Testing
- The right design
- Refactoring
- Pair programming
- Collective ownership
- Continuous integration
- 40-hour work week
- On-site customer
- Coding practices
|
|
Basic XP practices
The separation of roles is
embodied in a practice called The Planning Game.
Balance business considerations against technical considerations. Plan appropriately. Remember that
business people make business decisions. Those decisions include scope, priority of product
features, composition of releases and dates of releases. Technical people make technical decisions
about the project. They estimate time frames and the consequence of one function over another.
They also define the development process and detailed scheduling. Like a real game,
the planning game has objectives and rules that guide each side, business and technical, in creating useful software.
eXtreme programming is best accomplished if we think in terms of small releases.
Make releases really reachable. Instead of annually or biannually, think in terms of no more than one month or two, providing the opportunity to steer a project by adjusting or shifting at each
release cycle. Remember, however, that each release should make sense as a whole. Releasing half
a feature merely to reduce a release cycle is not an acceptable alternative.
Communication is key in any development project. In XP a shared mental model
between the business people and technical people is created, and it
defines a simple story of how the system works. It becomes a metaphor for discussions about the
system. With a strong consensus for describing the underlying goals, the project makes significant
strides toward success.
Remember how snooty some are when they write code and hand it off
to the second-class testing organization? Gone are those days of yore! We write our own test code and must write it before composing the code itself. All unit tests must run at 100%. Acceptance
testing should be automated for every feature so we know when the release iteration is
completed. Think about every way to break a piece of code and write a test case to exercise it.
Believe it or not, this aggressive testing will actually increase the speed of development
while improving and proving your code.
Design for today. Keep it simple. The right design has no duplicated logic and states every
intention important to the programmers. It runs all the test scenarios and has the fewest possible
classes and methods. We are too used to designing for tomorrow. With XP you put in
what you need when you need it. With all projects, the design will change over time
as new function and releases occur. Design for today because the next practice will provide the
means for later change.
It's OK to change code to change a system design. Refactoring is changing existing
code to simply add additional features. It is not, however, a way to add code on speculation
because it might be a good idea. Removing duplicate code, improving code structure, or enhancing
design are all good basis for change.
Did anyone ever say two heads are better than one? The most controversial concept of XP is
the idea of pair programming. This is the notion that all production code is
written with two people looking at one machine, with one keyboard and one mouse. A manager's
production nightmare! But, paired programming really works. One partner thinks about how to best
implement a method while the other thinks strategically: Will the approach work? What are some
other test cases? How can we simplify the code?
If pairs become responsible for the output then surely collective ownership becomes the norm. Any programmer who sees an opportunity to add value to any part of the code is able -- no, is
compelled and required -- to do so. Every programmer takes responsibility for the
entire system. Not everyone understands every part equally well, but everyone knows something about
every part. We achieve the collective plus individuality of ideas!
With everyone involved, continuous integration and testing is done every few hours or every day at least. The pair currently integrating their latest code changes becomes the obvious set responsible for fixing a failed test. One hundred percent of tests must run -- there is no room for less.
But while all tests must run, effective planning centers on a 40-hour work week. People must be
fresh and creative, careful and confident. Sixty-hour weeks for many weeks lead to carelessness and
mistakes. Constant overtime is probably a symptom of a serious problem. A single week of overtime
from time to time is OK. However, when the second straight week of overtime begins, look for the
underlying problem.
eXtreme Programming employs yet another novel idea -- an on-site customer. Previously the customer quickly articulated requirements, but now an on-site customer becomes a member of the implementation team. This team member becomes invaluable to respond to questions, resolve disputes and set small-scale priorities. The on-site customer must, however, be real. They must be someone who understands the entire system, and someone who might be a candidate to actually use it.
If all developers can change all parts of the system at all times, we cannot afford different
coding practices. It should become impossible to say who, or which team, wrote what code. Programmers awake! XP means you go along with the majority on code formatting.
This is XP. How can this possibly work, you ask? Think of how
the practices reinforce each other. Weaknesses in one are remedied by the strengths of the others.
The interaction between the practices provide the balance if everyone is employing the practices of
XP. Remember, all 12 of the practices must be done.
Strategies for implementation
Several strategies could be used to implement the XP methodology. But, a strategy where a manager is
responsible for all decisions, or where everyone does what they want, are both doomed. In
applying the XP principles, we believe a manager should highlight what needs to be done
without assigning work. A strategy that assumes programmers want to do a good job for the team
effort over a personal goal, and one in which a programmer wishes the team to do a great job,
provides success.
Management strategy for eXtreme programming means applying XP to local conditions, and helping
resolve differences with company cultures. We also travel light with very little
overhead. Long meetings and lengthy status reports disappear. Measurements are honest. Metrics
are gathered at a realistic level of accuracy without accounting for every second or minute. This
is an environment where people take precedence over process. We are not plug-compatible programming
units.
The planning strategy brings the team together to decide on scope and priorities, and to estimate
costs and schedules. The outcome should be a plan that everyone has confidence can and
should be executed to produce the required system. The plan also provides a benchmark for feedback.
But planning doesn't stop there. Planning is carried out at lower levels of the system, is
continuous, and constantly incorporates the latest feedback.
The development, testing, and design strategies are intricately tied to the practices that are
relevant to each process. For development, these are continuous integration, pair programming, and
collective ownership. For testing, these are unit tests and acceptance tests. And design relies on
"the simplest thing that could possibly work," and concrete feedback of abstract ideas through
implemented code.
Simple yet hard
eXtreme Programming is simple yet hard. Why? Because, well, it's hard to do simple things. As odd
as this sounds, we've been conditioned to design for tomorrow and to admire those who can make
complicated things work. It's also hard to admit you don't know something, and eXtreme Programming is based on the premise that you develop only as fast as you learn. Finally, it's hard to collaborate; since
childhood we've been rewarded on individual achievement. Despite these hurdles, eXtreme
Programming works.
We hope you found this introduction to the value, principles and practices of eXtreme Programming useful.
Having been intrigued with the idea of eXtreme Programming, our immediate organization decided to
use the concepts in a project called GoForIt. Over the next several months members of our team
will collaborate to share our experiences with XP and lessons we are learning. By following these
articles we hope you will experience an actual project implementation using eXtreme Programming.
Stay tuned...
Watch for our next installment of the Go-ForIt chronicles. To see the other articles in our tale of dragonslaying, go to our overview.
Resources
About the authors | 
| |
Willy Farrell is the Lead e-business Architect for Developer Relations Technical Consulting in Austin, Texas, providing education, enablement, and consulting to IBM Business Partners. He has been programming computers for a living since 1980, began using Java in 1996, and joined IBM in 1998. Willy holds the following technical certifications, among others: Java Programmer, VisualAge for Java Solution Developer, MQSeries Solutions Expert, WebSphere Application Server Solution Developer, XML Developer, and IBM e-business Solution Technologist. You can reach him at willyf@us.ibm.com. |
| | |
Mary-Rose Fisher began working in the area of object technologies with Taligent and OpenDoc in the mid-1990s. As the Java language evolved, she became the focal point for IBM ISV e-business developers in porting to the RS/6000 and AIX. Currently she is as an e-business Architect in the Developer Relations organization. You can reach her at mrfisher@us.ibm.com. |
Rate this page
| 
