We are the first to admit that some parts of XP sound a bit odd to "classically
trained" (or "classically untrained") programmers. These tend to have the greatest
shock value:
You write tests before you write code to exercise the tests
You let the design evolve to fit changing requirements
You program in pairs, often sharing a single keyboard and mouse
If you're like us, you didn't cut your teeth in an environment like this. It takes
some getting used to. The way to handle this objection is to focus on the freedom XP
can give developers to concentrate on writing code. That is what they love to do,
after all.
Writing tests before they write code feels weird at first, but it is similar to what
they've always done. When you write code, you start with some functional
requirement and then map that to code somehow. The code is in your head for at
least an instant before you write it down. Stop! Now write a test that will verify what
you expect that code to do. Then write the code to make the test work. When most
developers stop to reflect, they will find that doing things this way forces them to
think about design and then to verify it quickly. It may seem that it slows you down
at first. And, when you are first figuring out how to write tests it probably does.
However it doesn't take long to see the benefits. Work through it!
The results are phenomenal. Your code will be simpler, since you only had to
write enough of it to get your tests to pass. You don't have to be afraid of other
people changing your code, since they can run the tests for validation. Having tests
gives your manager confidence that he can let you move on to greener pastures. And
tests also serve as good documentation, so you're killing many birds with one stone.
The best way we've seen is to start writing the tests yourself even while the other
developers refuse. Every time you experience one of those "Thank God, I had the
tests" moments (trust us, it won't take long), talk about it. Pretty soon you will be
test-infected2. The infection will spread.
Letting design float with changing requirements feels odd, too. People ask us
often if we're nuts. No, we're not. (Well, at least not due to this issue). We're
realistic. Your design will need to change whether you accept that reality or not. XP
just makes that normal. You won't let design fall on the floor, you'll simply spread it
out. Rather than doing it all up front, you'll do it "just in time."
Again, the results of incremental design are amazing. Changes in requirements
aren't cause for mass suicide. Your designs will reflect reality instead of theory that
you guessed about months ago before you knew what you know now. Designing this
way produces code you can be proud of, not a jalopy you cobbled together.
On the other hand, this is not an excuse to do no design! As soon as you realize
that more than one object is calling the database, and that embedding database
connectivity into your code is making it "complex" (which may or may not be before
you write a line of code, depending on your experience), it is time to consider
seperating a database layer from your domain layer. We've seen the benefit on one
project where the database was switched on us twice due to business negotiations
gone bad. Due to our good design, switching the database out (and adjusting the
persistence layer) could be done without having to change many of the other objects.
The point is that we didn't need to spend months designing the persistence layer to
figure that out.
On another project, we needed to convert one key object to XML. We thought,
"What is the simplest thing that could possibly work?". One of the developers did a
quick web search and found a free product that would automatically do the
conversion. However, it was fairly large and we'd have to figure out how to use it.
Then someone noted that converting that relatively simple object into XML could be
done in a single method without this product. Done. If the requirements change and
we need to start converting more complex objects, or a lot more of them, we'll revisit
our approach and this product. Until then, we are moving on to other stories.
The bottom line is that feeling awkward is normal when you're doing something
new. Think about it like learning to ride a bike. When you started you stunk at, and
probably fell off once or twice. After you got the hang of it, it felt natural.
Thursday, 8 September 2011
XP Is Too Simplistic
Sound familiar? Managers said the same thing, but for a different reason.
XP challenges the perception of developers that no one understands what they
do and can't do it themselves. This is true to some degree. But it shouldn't be true
because of the process they use. XP takes the magic out of process and lets it live in
the code, where it belongs. The magic is in the results.
XP gets out of a developer's way. You produce no unnecessary documentation.
You get to focus on designing and developing good code. You get to enjoy your
time, rather than loathing having to come to work.
XP is not simplistic. It is simple, uncluttered. Some aspects of the discipline
aren't easy for developers (see the discussion of pair programming below), but it has
the best chance of any approach we have ever seen of fostering a rich environment
for programmers.
Often, when an experienced developer says this what they really mean is "I've
learned other ways to do software (which involves little programming) and my
career has advanced because of it. I don't want to go backwards (at least not careerwise).
And besides, I'm not as good at programming as I once was because I spend
most of my time doing higher level things." Very few of these people actually think
the higher level things they do are as fun or that the process they use to do those
higher level things are efficient. They are often scared that what they've gotten good
at will be looked at as less valuable.
XP challenges the perception of developers that no one understands what they
do and can't do it themselves. This is true to some degree. But it shouldn't be true
because of the process they use. XP takes the magic out of process and lets it live in
the code, where it belongs. The magic is in the results.
XP gets out of a developer's way. You produce no unnecessary documentation.
You get to focus on designing and developing good code. You get to enjoy your
time, rather than loathing having to come to work.
XP is not simplistic. It is simple, uncluttered. Some aspects of the discipline
aren't easy for developers (see the discussion of pair programming below), but it has
the best chance of any approach we have ever seen of fostering a rich environment
for programmers.
Often, when an experienced developer says this what they really mean is "I've
learned other ways to do software (which involves little programming) and my
career has advanced because of it. I don't want to go backwards (at least not careerwise).
And besides, I'm not as good at programming as I once was because I spend
most of my time doing higher level things." Very few of these people actually think
the higher level things they do are as fun or that the process they use to do those
higher level things are efficient. They are often scared that what they've gotten good
at will be looked at as less valuable.
XP Is Too New To Trust
Almost nobody makes a habit of being the sucker to use Release 1.0 of a
software product. This increases your project risk. To many, XP is at Release 1.0
right now. Maybe it is really at Release 1.x. So what?
When managers talk about new things like XP being risky, they are assuming
that the status quo is safer. We have seen that it isn't. If you stay on the status quo
curve, be ready to run out of oxygen. You cannot stay there and survive. The only
way to find out if XP is too risky to use is to try it. As we said in Chapter 2, you
don't have to try it on a mission-critical project first. But you have to try it so that
you can get feedback on whether or not it produces the results you want in your
environment.
If your manager doesn't micromanage, get a bunch of XP-friendly developers
together and give it a try. Show your manager the results. If the results are great,
you're on your way. If not, drop back and figure out why not. Then modify the
process as necessary and try again.
If your manager is more hands-on, ask your manger for permission to try XP for
two or three weeks. Then let them examine the results after a couple weeks and draw
their own conclusions. Ask them if extrapolating the results you saw on this first
project would flatten the curve. If it would, you've got a powerful argument in favor
of XP.
software product. This increases your project risk. To many, XP is at Release 1.0
right now. Maybe it is really at Release 1.x. So what?
When managers talk about new things like XP being risky, they are assuming
that the status quo is safer. We have seen that it isn't. If you stay on the status quo
curve, be ready to run out of oxygen. You cannot stay there and survive. The only
way to find out if XP is too risky to use is to try it. As we said in Chapter 2, you
don't have to try it on a mission-critical project first. But you have to try it so that
you can get feedback on whether or not it produces the results you want in your
environment.
If your manager doesn't micromanage, get a bunch of XP-friendly developers
together and give it a try. Show your manager the results. If the results are great,
you're on your way. If not, drop back and figure out why not. Then modify the
process as necessary and try again.
If your manager is more hands-on, ask your manger for permission to try XP for
two or three weeks. Then let them examine the results after a couple weeks and draw
their own conclusions. Ask them if extrapolating the results you saw on this first
project would flatten the curve. If it would, you've got a powerful argument in favor
of XP.
XP Is Too Informal
Managers may take issue with XP not having lots of documentation. They may
claim that XP is an excuse to code like a cowboy – it's hacking without
documenting. They might also think that Stories aren't formal enough to give
programmers enough information.
The most common source of the informality objection is a bad experience in the
past. Most managers have been burned before. They have no desire to repeat the
unpleasant experience. But they throw the baby out with the bathwater. They assume
that formality will increase their chances of winning. Nothing could be further from
the truth.
Lots of documents do not make software better. Clearer code does. The only
way to keep code clean is not to clutter it up with unnecessary stuff, and to scrub as
you go. XP lets you concentrate on doing both. Build only what the Stories for the
current iteration call for. Refactor mercilessly.
Using Stories instead of detailed specs is no excuse for being lazy. We still have
to get all of the requirements. We just don't need all of the details for ones thatwon't be implemented for a while. Experience tells us that these will be completely
different then anyway. Remember that a Story is a commitment to have a future
conversation to flesh out the details. You need to verify the details of any Story
before you implement it, so we defer the detail gathering until then. XP requires that
you produce all necessary documentation, but discourages production of
unnecessary wallpaper.
By the way, why is an approach that encourages us to write tests before we code
less formal than one that makes us write documentation before we code? It's often
important to question the value of formality and focus on what we really want…
results. If the formality we are familiar with gets us the results we want, why
change? The only reason to change is if the informality gets us the results we want
faster, cheaper, and/or more reliably. Call us crazy, but we'd go with running tests
over paper documentation anyday when we are looking for reliability. If reliability
doesn't matter, then all that's left is faster and cheaper. We're going out on a limb
here, but we'd venture to say that producing formal documentation does not make
the process faster or cheaper.
What you need to point out is that many of those skills are still needed. Their
ability to do "architecture" is still needed. They need to help find a Metaphor and
make sure people are focused on how the pieces fit together. They just need to do
more of it via verbal communication and interaction. Instead of being frustrated that
people don't understand their architecture and that they don't have time to make it
work, their time will be freed up to spend more time communicating the
architectural issues and assisting the other developers. As a bonus, their hands-on
technology skills will increase.
claim that XP is an excuse to code like a cowboy – it's hacking without
documenting. They might also think that Stories aren't formal enough to give
programmers enough information.
The most common source of the informality objection is a bad experience in the
past. Most managers have been burned before. They have no desire to repeat the
unpleasant experience. But they throw the baby out with the bathwater. They assume
that formality will increase their chances of winning. Nothing could be further from
the truth.
Lots of documents do not make software better. Clearer code does. The only
way to keep code clean is not to clutter it up with unnecessary stuff, and to scrub as
you go. XP lets you concentrate on doing both. Build only what the Stories for the
current iteration call for. Refactor mercilessly.
Using Stories instead of detailed specs is no excuse for being lazy. We still have
to get all of the requirements. We just don't need all of the details for ones thatwon't be implemented for a while. Experience tells us that these will be completely
different then anyway. Remember that a Story is a commitment to have a future
conversation to flesh out the details. You need to verify the details of any Story
before you implement it, so we defer the detail gathering until then. XP requires that
you produce all necessary documentation, but discourages production of
unnecessary wallpaper.
By the way, why is an approach that encourages us to write tests before we code
less formal than one that makes us write documentation before we code? It's often
important to question the value of formality and focus on what we really want…
results. If the formality we are familiar with gets us the results we want, why
change? The only reason to change is if the informality gets us the results we want
faster, cheaper, and/or more reliably. Call us crazy, but we'd go with running tests
over paper documentation anyday when we are looking for reliability. If reliability
doesn't matter, then all that's left is faster and cheaper. We're going out on a limb
here, but we'd venture to say that producing formal documentation does not make
the process faster or cheaper.
What you need to point out is that many of those skills are still needed. Their
ability to do "architecture" is still needed. They need to help find a Metaphor and
make sure people are focused on how the pieces fit together. They just need to do
more of it via verbal communication and interaction. Instead of being frustrated that
people don't understand their architecture and that they don't have time to make it
work, their time will be freed up to spend more time communicating the
architectural issues and assisting the other developers. As a bonus, their hands-on
technology skills will increase.
XP Is Simplistic
Managers might say that XP glosses over complexity, or that it replaces thinking
ahead with simplistic naiveté.
They are assuming that your existing approaches handle complexity better and
let you think far enough ahead. Most approaches we have used other than XP simply
don't. They deal with complexity by trying to figure it all out up front. You draw
pictures, create documents, try to cover all the bases and anticipate everything. The
problem is that you're guessing. Pretty pictures are no substitute for experience.
XP is simple, not simplistic. It recognizes the reality that things change. You
cannot predict the future with any degree of accuracy. You cannot plan for
everything. You might guess right, but that's all it is. XP says, "Don't even try."
Instead, do things in a way that lets you respond quickly and well to emergent
reality. What does that look like?
The Planning Game helps to identify items with the biggest risk. We tackle these
first. Planning is so important that we do it daily, based on real experience and a
working system, not once based on our best guess when all we have is theory. Two
sets of eyes see all production code, which minimizes the number of sides that are
"blind." Because there is no code ownership, and we have tests for everything, we
are able to move our best developers to the problem areas that need their expertise,
without leaving the rest of the project in the lurch. And so on.
XP forces a team to find real problems sooner, without having to guess at what
they are. It reduces the number of blind spots. Its rapid feedback allows it to be
simple without being simplistic.
Before assuming too much, ask the manager why he thinks it is simplistic, and
what additional practices he thinks are necessary to make up for the simplicity. If
they can supply them, ask what it is about those practices will help you accomplish
that the other twelve practices do not. In particular as why they think it will get him
the results he wants faster. Often it is a misunderstanding of what the practices are.
We find the biggest objections in this category are that more documentation is
needed to help current and future developers understand the system. See the
sections on Communication and Testing to provide fodder for your argument.
ahead with simplistic naiveté.
They are assuming that your existing approaches handle complexity better and
let you think far enough ahead. Most approaches we have used other than XP simply
don't. They deal with complexity by trying to figure it all out up front. You draw
pictures, create documents, try to cover all the bases and anticipate everything. The
problem is that you're guessing. Pretty pictures are no substitute for experience.
XP is simple, not simplistic. It recognizes the reality that things change. You
cannot predict the future with any degree of accuracy. You cannot plan for
everything. You might guess right, but that's all it is. XP says, "Don't even try."
Instead, do things in a way that lets you respond quickly and well to emergent
reality. What does that look like?
The Planning Game helps to identify items with the biggest risk. We tackle these
first. Planning is so important that we do it daily, based on real experience and a
working system, not once based on our best guess when all we have is theory. Two
sets of eyes see all production code, which minimizes the number of sides that are
"blind." Because there is no code ownership, and we have tests for everything, we
are able to move our best developers to the problem areas that need their expertise,
without leaving the rest of the project in the lurch. And so on.
XP forces a team to find real problems sooner, without having to guess at what
they are. It reduces the number of blind spots. Its rapid feedback allows it to be
simple without being simplistic.
Before assuming too much, ask the manager why he thinks it is simplistic, and
what additional practices he thinks are necessary to make up for the simplicity. If
they can supply them, ask what it is about those practices will help you accomplish
that the other twelve practices do not. In particular as why they think it will get him
the results he wants faster. Often it is a misunderstanding of what the practices are.
We find the biggest objections in this category are that more documentation is
needed to help current and future developers understand the system. See the
sections on Communication and Testing to provide fodder for your argument.
XP Flattens the Curve
Change is the reality of software development. You can't anticipate everything,
no matter how much you plan. Traditional approaches to software development
force you to climb an asymptotic cost of change curve. The only way to produce
good software, and to stay sane, is to use a flatter curve.
If you want to win, you've got to flatten the curve and keep it flat. XP focuses
on living in the self-fulfilling reality of a flatter curve, and it gives you tools to get
there.
Developing software is a challenge, no matter how you go about it. But XP
proposes that we apply four values consistently to give ourselves a better chance to
succeed:
Simplicity
Communication
Feedback
Courage
The fundamental premise of XP is that application of these values via consistent
principles and practices will flatten the curve. Those principles and practices accept
reality. Requirements change. Scope creeps. Two people working together are
simply more productive than the same two people working alone. Not every
programmer is Einstein. Some things are out of your control. Stuff happens. Accept
it and get going.
XP is no silver bullet. There are still forces outside our control (competitors,
human fallibility, etc.). But if the curve is flat, you can walk instead of climbing.
That way, you can observe the scenery instead of trying not to fall.
XP also isn't just spin on undisciplined hacking. Applying the principles and
practices takes discipline. It takes discipline to write tests first, to integrate often, to
get all the tests to run before moving on, to pair program. In fact, the one lesson we
should draw from "hard" engineering is that discipline is important.
The difference between the discipline needed for XP and the discipline needed
for civil software engineering is in the results. XP gets you reliable, flexible software
on a daily basis. You can win with that, whether or not you have the diagrams.
When XP is given a fair shot, both programmers and business people enjoy it.
And why wouldn't it be? Fighting uphill battles is tiring. The flatter the terrain, the
less fatiguing the battle. In fact, it often doesn't even fill like a battle, especially to
those who are used to fighting on a slope.
no matter how much you plan. Traditional approaches to software development
force you to climb an asymptotic cost of change curve. The only way to produce
good software, and to stay sane, is to use a flatter curve.
If you want to win, you've got to flatten the curve and keep it flat. XP focuses
on living in the self-fulfilling reality of a flatter curve, and it gives you tools to get
there.
Developing software is a challenge, no matter how you go about it. But XP
proposes that we apply four values consistently to give ourselves a better chance to
succeed:
Simplicity
Communication
Feedback
Courage
The fundamental premise of XP is that application of these values via consistent
principles and practices will flatten the curve. Those principles and practices accept
reality. Requirements change. Scope creeps. Two people working together are
simply more productive than the same two people working alone. Not every
programmer is Einstein. Some things are out of your control. Stuff happens. Accept
it and get going.
XP is no silver bullet. There are still forces outside our control (competitors,
human fallibility, etc.). But if the curve is flat, you can walk instead of climbing.
That way, you can observe the scenery instead of trying not to fall.
XP also isn't just spin on undisciplined hacking. Applying the principles and
practices takes discipline. It takes discipline to write tests first, to integrate often, to
get all the tests to run before moving on, to pair program. In fact, the one lesson we
should draw from "hard" engineering is that discipline is important.
The difference between the discipline needed for XP and the discipline needed
for civil software engineering is in the results. XP gets you reliable, flexible software
on a daily basis. You can win with that, whether or not you have the diagrams.
When XP is given a fair shot, both programmers and business people enjoy it.
And why wouldn't it be? Fighting uphill battles is tiring. The flatter the terrain, the
less fatiguing the battle. In fact, it often doesn't even fill like a battle, especially to
those who are used to fighting on a slope.
XP Doesn’t Give Us Enough Information
Developers don't like to create a lot of documentation (or any, we suppose), but
they do like to have enough information to act on. They don't want to fly blind.
Nothing hurts quite as badly as working like a dog to deliver something nobody
likes. We hear often that XP sets you up for failure by not having enough design
documentation, and by depending on stories instead of comprehensive specs.
Ken and Roy have worked on lots of projects. In most cases, your first day
follows the same pattern. You walk in and somebody hands you a functional spec, a
technical spec, and/or a detailed design document. Nobody ever reads them and
they're hopelessly out of date, you're told, but here they are. This is no better than
having no documentation at all. Often, it's worse.
Several years ago (pre-XP), Ken went to help a group who had lost a developer
due to a family emergency. He was told that, when he got there, they were a day or
two away from delivering "Phase 1", a functional prototype of a subset of the
system. Since the chances were that he couldn't help finish that, (by the time he got
up to speed, they'd be done), he should begin thinking about the next version of the
system. Being an agreeable sort, Ken said, "fine, how would you suggest I get the
background I need without getting in your way?". "Read these documents. They are
fairly complete, but mostly out of date. Section 6 gives a pretty decent account of
the motivation for what we want to do. The prototype doesn't follow much of the
implied design, but it works and is probably a bit more thorough."
much design to speak of (at least nothing that could be reasonably implemented),
and Section 6 was full of acronyms and phrases that were not in Ken's vocabulary.
There was a lot more to read, but at a cursory glance Ken didn't think he would get
any more benefit from reading it (other than the bliss that comes at the end of the
day when you get to stop reading), so he asked if he might review the prototype to
help him understand how they had approached the problem for the prototype and
begin to make recommendations of what approaches they might keep and what
approaches should change. Permission was granted since it turned out that Phase 1
still wasn't over due to a lot of bugs in the prototype that the rest of the team was
working hard to get out.
As he studied the prototype, he discovered that it was built on top of a
framework that another group had built for a different application. Although there
was little documentation on that framework, an occasional class comment explained
some of the trickier parts and the code was clear enough that he could figure out the
rest.
On day three of reviewing the prototype and doing some experiments to explore
how they might approach things differently (day 5 of being there… 4 days over the
day Phase 1 was supposed to be complete), Ken overheard the morning panic
meeting that happened to be held in the middle of his cube set. (Each developer had
their own corner of the square, and a small round conference table was in the
middle. The other 3 developers were working on finishing Phase 1). One of the
developers was sharing with the manager that the bug they were discussing was a
bear and that it would be nice if he could do something like X-Y-Z, but that was
going to take some time. Ken interrupted, "Excuse me, Bob, but I couldn't help
overhearing. There is a feature of the framework that already does X-Y-Z."
"Really?". "Well, at least I think so. After you're done the meeting, I'll look at it with
you and we can make sure it helps you do what I think I heard you say." "Cool.
(turning back to the manager) Well, if Ken's right, then we can knock that one out
today and I can look at some of the other bugs that should be easier."
Ken was right, and the next day at the "we just gotta get the last bugs out of this
thing and we'll be done with it" meeting a few more hairy bugs came up. This time,
Ken was called on. "Hey, Ken, you wouldn't happen to know if there is anything in
the framework that will let me U-V-W, do you?". "Actually, I think there is
something that will do U-V for you. And the W part is a piece of cake.".
What's the point of the story?
All the developer's had read the documentation and realized it wasn't that helpful
so they threw something together anyway. They were fortunate enough to have
some decent code from the other group to build upon, but they never "read the
code". The documentation was what was supposed to give them understanding.
Since the framework they were sitting on didn't have much documentation, they
never tried to understand it. Somebody showed them how to do something with it,
and they ran forward. If they would have taken two days to read the code instead of
reading the documentation, they probably would have been done Phase 1. The code
was up to date and it provided something useful to study. The documentation
provided almost no value. It certainly provided less payback than the months of
time and money that was put into producing it.
When Ken asked the "Phase 1" developers how they built the prototype based on
the information in the document, he was told that they didn't. They had read the
document and still didn't know what to do. So, they started meeting with the users
who explained to them what they really wanted, and built the prototype in between
meetings based on what they learned during the previous meetings.
XP does NOT recommend that you don't produce documentation. It just says
you should not spend time creating any unnecessary documentation. You need to
figure out what that is. Our recommendation is to throw out pre-conceived notions
of what is necessary and assume you don't need it. Then, when somebody asks for it,
ask them why they need it. If they "need to understand something", offer to explain
it to them. If they still need it, consider it. See the section on Communication, Not
Documentation.
Unless there is some external requirement to do so (e.g. in a regulated
environment), we do the simplest thing that could possibly work for documentation:
Stories, tasks, the developer-customer discussions around them, and the
acceptance tests are the only spec you'll ever need.
The "system documentation" is mostly in the code and the unit tests
which always tell you how the code works today.
Recently, we were in a meeting with a prospective client. Part of the
conversation went like this:
Client: We have this software that was written several years ago by someone
who is no longer with the company. We brought in a new person to try to add some
new functionality and he's having a rough time.
Ken: Do you have out of date design documentation?
Client: Yes.
Ken: Would you rather have a set of working tests?
Client: Absolutely.
Specs are never comprehensive. In fact, until you have clear consistent
acceptance tests, they are far from exact. A recent study indicated that the average
requirements document is 15% complete and 7% accurate, and that the length of
lie" of BDUF. You simply can't think of everything to the last detail and if the
requirements aren't complete, the chance of the design being adequate is slim to
none.
It is better to admit that the requirements are vague from the beginning, and
work on the details in the form of acceptance tests as they are needed. That's really
the hard part. It is seemingly impossibly in some cases until you have something
half-working.. This is how it happens anyway, but usually the customer and
developer expectations are all out of whack. Customers think they'll get the
implementation of the whole spec at once, but developers prioritize it and work on it
sequentially. The developers will most likely have different priorities than the
customer, so the wrong people are prioritizing. If you make customer prioritization
the norm, both groups have the same expectation. We'll identify all the big pieces
(stories), we'll prioritize them so that everybody knows what we're working on and
why, and we'll flesh out the details when it comes time to do each one (tasks and
estimates).
Our initial estimates are no more unreliable than the requirements. (Our
estimates are at least 7% accurate). Once requirements are specified as
unambiguous acceptance tests, we will get much better estimates. Until then (and
beyond), we should work within reality.
Tests and Code are a better system documentation than anything else could be. It
is also the most efficient way of getting accurate documentation. If you're trying to
learn a new part of the system, you eventually have to go from words to code
anyway in order to really understand what's going on. Why waste time on the
overhead of keeping paper updated? We have never heard a good reason.
Earlier this year, Ken was in London and was a guest at the eXtreme Tuesday
Club4. The first question he got was something like, "How does XP map
requirements to code?". Ken's answer was "Why do you need to map it to code?".
"So you can see how a the requirements are met." "The requirements are met when
the acceptance test passes." "Yes, but what if the requirements changed". "Then the
acceptance test changed". "Yes, but how do you know what change in requirements
caused what change in the code." "Why do you need to know that?". "To make sure
that the requirements are met." "The acceptance tests do that… Look, you are
assuming that there is a requirement to track requirements to code. I'm trying to
build a product that meets the requirements. Why would I waste time doing all of
this mapping. The customer doesn't want a map of requirements. They want the
requirements met. Of course they are going to change. So, we need a new test or set
of tests and they have to pass." End of discussion.
XP gives you enough information to do your job as well as you can, without
distracting you with too much.
they do like to have enough information to act on. They don't want to fly blind.
Nothing hurts quite as badly as working like a dog to deliver something nobody
likes. We hear often that XP sets you up for failure by not having enough design
documentation, and by depending on stories instead of comprehensive specs.
Ken and Roy have worked on lots of projects. In most cases, your first day
follows the same pattern. You walk in and somebody hands you a functional spec, a
technical spec, and/or a detailed design document. Nobody ever reads them and
they're hopelessly out of date, you're told, but here they are. This is no better than
having no documentation at all. Often, it's worse.
Several years ago (pre-XP), Ken went to help a group who had lost a developer
due to a family emergency. He was told that, when he got there, they were a day or
two away from delivering "Phase 1", a functional prototype of a subset of the
system. Since the chances were that he couldn't help finish that, (by the time he got
up to speed, they'd be done), he should begin thinking about the next version of the
system. Being an agreeable sort, Ken said, "fine, how would you suggest I get the
background I need without getting in your way?". "Read these documents. They are
fairly complete, but mostly out of date. Section 6 gives a pretty decent account of
the motivation for what we want to do. The prototype doesn't follow much of the
implied design, but it works and is probably a bit more thorough."
much design to speak of (at least nothing that could be reasonably implemented),
and Section 6 was full of acronyms and phrases that were not in Ken's vocabulary.
There was a lot more to read, but at a cursory glance Ken didn't think he would get
any more benefit from reading it (other than the bliss that comes at the end of the
day when you get to stop reading), so he asked if he might review the prototype to
help him understand how they had approached the problem for the prototype and
begin to make recommendations of what approaches they might keep and what
approaches should change. Permission was granted since it turned out that Phase 1
still wasn't over due to a lot of bugs in the prototype that the rest of the team was
working hard to get out.
As he studied the prototype, he discovered that it was built on top of a
framework that another group had built for a different application. Although there
was little documentation on that framework, an occasional class comment explained
some of the trickier parts and the code was clear enough that he could figure out the
rest.
On day three of reviewing the prototype and doing some experiments to explore
how they might approach things differently (day 5 of being there… 4 days over the
day Phase 1 was supposed to be complete), Ken overheard the morning panic
meeting that happened to be held in the middle of his cube set. (Each developer had
their own corner of the square, and a small round conference table was in the
middle. The other 3 developers were working on finishing Phase 1). One of the
developers was sharing with the manager that the bug they were discussing was a
bear and that it would be nice if he could do something like X-Y-Z, but that was
going to take some time. Ken interrupted, "Excuse me, Bob, but I couldn't help
overhearing. There is a feature of the framework that already does X-Y-Z."
"Really?". "Well, at least I think so. After you're done the meeting, I'll look at it with
you and we can make sure it helps you do what I think I heard you say." "Cool.
(turning back to the manager) Well, if Ken's right, then we can knock that one out
today and I can look at some of the other bugs that should be easier."
Ken was right, and the next day at the "we just gotta get the last bugs out of this
thing and we'll be done with it" meeting a few more hairy bugs came up. This time,
Ken was called on. "Hey, Ken, you wouldn't happen to know if there is anything in
the framework that will let me U-V-W, do you?". "Actually, I think there is
something that will do U-V for you. And the W part is a piece of cake.".
What's the point of the story?
All the developer's had read the documentation and realized it wasn't that helpful
so they threw something together anyway. They were fortunate enough to have
some decent code from the other group to build upon, but they never "read the
code". The documentation was what was supposed to give them understanding.
Since the framework they were sitting on didn't have much documentation, they
never tried to understand it. Somebody showed them how to do something with it,
and they ran forward. If they would have taken two days to read the code instead of
reading the documentation, they probably would have been done Phase 1. The code
was up to date and it provided something useful to study. The documentation
provided almost no value. It certainly provided less payback than the months of
time and money that was put into producing it.
When Ken asked the "Phase 1" developers how they built the prototype based on
the information in the document, he was told that they didn't. They had read the
document and still didn't know what to do. So, they started meeting with the users
who explained to them what they really wanted, and built the prototype in between
meetings based on what they learned during the previous meetings.
XP does NOT recommend that you don't produce documentation. It just says
you should not spend time creating any unnecessary documentation. You need to
figure out what that is. Our recommendation is to throw out pre-conceived notions
of what is necessary and assume you don't need it. Then, when somebody asks for it,
ask them why they need it. If they "need to understand something", offer to explain
it to them. If they still need it, consider it. See the section on Communication, Not
Documentation.
Unless there is some external requirement to do so (e.g. in a regulated
environment), we do the simplest thing that could possibly work for documentation:
Stories, tasks, the developer-customer discussions around them, and the
acceptance tests are the only spec you'll ever need.
The "system documentation" is mostly in the code and the unit tests
which always tell you how the code works today.
Recently, we were in a meeting with a prospective client. Part of the
conversation went like this:
Client: We have this software that was written several years ago by someone
who is no longer with the company. We brought in a new person to try to add some
new functionality and he's having a rough time.
Ken: Do you have out of date design documentation?
Client: Yes.
Ken: Would you rather have a set of working tests?
Client: Absolutely.
Specs are never comprehensive. In fact, until you have clear consistent
acceptance tests, they are far from exact. A recent study indicated that the average
requirements document is 15% complete and 7% accurate, and that the length of
lie" of BDUF. You simply can't think of everything to the last detail and if the
requirements aren't complete, the chance of the design being adequate is slim to
none.
It is better to admit that the requirements are vague from the beginning, and
work on the details in the form of acceptance tests as they are needed. That's really
the hard part. It is seemingly impossibly in some cases until you have something
half-working.. This is how it happens anyway, but usually the customer and
developer expectations are all out of whack. Customers think they'll get the
implementation of the whole spec at once, but developers prioritize it and work on it
sequentially. The developers will most likely have different priorities than the
customer, so the wrong people are prioritizing. If you make customer prioritization
the norm, both groups have the same expectation. We'll identify all the big pieces
(stories), we'll prioritize them so that everybody knows what we're working on and
why, and we'll flesh out the details when it comes time to do each one (tasks and
estimates).
Our initial estimates are no more unreliable than the requirements. (Our
estimates are at least 7% accurate). Once requirements are specified as
unambiguous acceptance tests, we will get much better estimates. Until then (and
beyond), we should work within reality.
Tests and Code are a better system documentation than anything else could be. It
is also the most efficient way of getting accurate documentation. If you're trying to
learn a new part of the system, you eventually have to go from words to code
anyway in order to really understand what's going on. Why waste time on the
overhead of keeping paper updated? We have never heard a good reason.
Earlier this year, Ken was in London and was a guest at the eXtreme Tuesday
Club4. The first question he got was something like, "How does XP map
requirements to code?". Ken's answer was "Why do you need to map it to code?".
"So you can see how a the requirements are met." "The requirements are met when
the acceptance test passes." "Yes, but what if the requirements changed". "Then the
acceptance test changed". "Yes, but how do you know what change in requirements
caused what change in the code." "Why do you need to know that?". "To make sure
that the requirements are met." "The acceptance tests do that… Look, you are
assuming that there is a requirement to track requirements to code. I'm trying to
build a product that meets the requirements. Why would I waste time doing all of
this mapping. The customer doesn't want a map of requirements. They want the
requirements met. Of course they are going to change. So, we need a new test or set
of tests and they have to pass." End of discussion.
XP gives you enough information to do your job as well as you can, without
distracting you with too much.
Write the Tests, Run the Tests
Write tests before you write the code to implement them. This will feel
odd, but you'll get better with time. Soon, it will feel odd not to write
tests first.
If you are like most of the readers of XP Explained, you are already convinced
that having tests is a good thing. You also aren't in the habit of writing tests before
you write code. You're probably a little intimidated or confused by the idea. We
typically hear things like this:
How can I write tests before I've written the code I'm going to test? I
don't even know what the classes are going to look like yet. They're
going to evolve.
Ken used to say stuff like this back in the 80s when he heard some proponents of
Objective-C claim that each class should have associated tests that should be written
first. He has now confessed and repented. You need to write tests first precisely
because you don't know what the classes are going to look like yet, and because
they are going to evolve.
Writing tests first keeps entropy from destroying your code. We write tests.
Then we write just enough code to get the tests to pass, no more. That is the best
way to keep your code clean.
Nothing gives you more confidence when changing code than having immediate
feedback about whether or not your changes broke anything. That's what having
tests does for you. Without the tests, you can't have confidence. Without confidence,
code doesn't get changed, even when it needs it.Better still, we have found that well-written unit tests are some of the best
documentation possible. They communicate the intent of the code being tested better
than any description on paper ever could. We can kill two birds with one stone.1
Keeping Code Clean
Writing the bare minimum code necessary to make the tests run keeps you from
wasting time on extra features. These hooks you might need later usually have to
change once to you get to "later," if they're ever used at all. But without the tests
there to guide you while you write code, the temptation to design for the future is
just too great.
Writing the minimum necessary code the first time around ensures that the
refactoring you do later isn't a complete overhaul. You can't get it perfect the first
time all the time. You will refactor your code. But start with the simplest code that
could possibly work. If your refactoring turns into redesign on a regular basis, your
velocity will tank. Moving at top speed is your bread and butter. Guard your velocity
with your life.
Think of this like keeping a room clean. Roy's mother used to say that doing that
is simple. Don't let the room get dirty. If you let the dirt build up, cleaning it
becomes a much bigger job that you end up putting off. Pretty soon you've got an
intractable mess. Roy's room is still always impeccably neat, by the way.
Confidence
In 1955, Dr. Jonas Salk administered his experimental polio vaccine to himself,
his wife, and their three sons. In a newspaper interview, he said that he did it
because he knew it would work. That's courage in action. Where did it come from?
Salk himself said, "It is courage based on confidence, not daring, and it is
confidence based on experience."
At least once or twice during most iterations on our projects, someone sees that
they need to make a radical change to some aspect of the system. When they do, a
bunch of tests break. This is expected. The pair works through the failures one by
one, modifying code to get each test to pass. This could take a few minutes or a few
hours. Invariably, when the pair is integrating the changes one member says, "Wow,
can you imagine how hard this would have been to do without these tests?!"
XP depends on courage, not bravado or reckless daring. Having tests to run to
confirm each change to our code keeps us from being reckless. It lets us proceed
bravely, knowing that we can prove to ourselves that our changes work. Instead of
holding lots of meetings to determine if a change will break something else, we can
just try it, run the tests, and find out. It's hard to be bold in the dark. The tests turn
on the lights.
Tests As Documentation
We have found that well-written tests are less painful to produce than other
forms of documentation. Not only that, they're better.
When you write tests first, you don't have to loop back and write documentation
later. It is an inseparable part of writing the code itself. It's sort of like having a
certain dollar amount each month taken out of your paycheck and put into a 401K.
After a while, you just don't notice it anymore. Any speed we lose in writing tests
first, we more than make up in reduced debugging time and reduced documentation
time. This is a great boost to your team's velocity in and of itself, not to mention the
increased velocity you get from having more confidence.
Even if this weren't true, tests still would be worth the effort. They are better
than any other kind of documentation we've ever seen.
Tests are more detailed than verbal descriptions on paper, without being
cluttered by extra words that describe what the code syntax says. Think about it. The
written code documentation we've seen wastes a lot of space saying things like "The
getMeal(PotPie) method on Shopper asks a Store for a PotPie. It casts this as a Meal
and calls addToBasket(Meal), passing it the Meal…" Why not just look at the code?
When you have a test, you can see a discrete Assertion (in JUnit) that tests this very
behavior and displays a message.
Tests also are more useful than other forms of documentation we've seen. They
give you a scenario in which the behavior of the code should work as intended.
Want to understand what a class does? Look at its tests to see exactly what you
should expect in certain scenarios. Other documentation struggles to do that. It
usually fails, if it tries at all.
Best of all, tests are absolutely up to date all the time (unless you're cheating).
What other documentation can claim that? We remember life before XP. Nine times
out of ten, whenever we walked onto a new project somebody gave us a document
that supposedly described the system we would be working on. It was usually a very
thick binder. As soon as they put this in our hands, they said something like, "This
should help a little, but it's out of date. Come talk to me after you read it." So what
earthly good was that document? Maybe it built character to put it together, but
that's all it was good for.
Not all non-code documentation is bad. When a customer needs a written
document other than code (say, for regulatory approval), you should produce it. XP
simply says you should produce only the written documents that you absolutely
odd, but you'll get better with time. Soon, it will feel odd not to write
tests first.
If you are like most of the readers of XP Explained, you are already convinced
that having tests is a good thing. You also aren't in the habit of writing tests before
you write code. You're probably a little intimidated or confused by the idea. We
typically hear things like this:
How can I write tests before I've written the code I'm going to test? I
don't even know what the classes are going to look like yet. They're
going to evolve.
Ken used to say stuff like this back in the 80s when he heard some proponents of
Objective-C claim that each class should have associated tests that should be written
first. He has now confessed and repented. You need to write tests first precisely
because you don't know what the classes are going to look like yet, and because
they are going to evolve.
Writing tests first keeps entropy from destroying your code. We write tests.
Then we write just enough code to get the tests to pass, no more. That is the best
way to keep your code clean.
Nothing gives you more confidence when changing code than having immediate
feedback about whether or not your changes broke anything. That's what having
tests does for you. Without the tests, you can't have confidence. Without confidence,
code doesn't get changed, even when it needs it.Better still, we have found that well-written unit tests are some of the best
documentation possible. They communicate the intent of the code being tested better
than any description on paper ever could. We can kill two birds with one stone.1
Keeping Code Clean
Writing the bare minimum code necessary to make the tests run keeps you from
wasting time on extra features. These hooks you might need later usually have to
change once to you get to "later," if they're ever used at all. But without the tests
there to guide you while you write code, the temptation to design for the future is
just too great.
Writing the minimum necessary code the first time around ensures that the
refactoring you do later isn't a complete overhaul. You can't get it perfect the first
time all the time. You will refactor your code. But start with the simplest code that
could possibly work. If your refactoring turns into redesign on a regular basis, your
velocity will tank. Moving at top speed is your bread and butter. Guard your velocity
with your life.
Think of this like keeping a room clean. Roy's mother used to say that doing that
is simple. Don't let the room get dirty. If you let the dirt build up, cleaning it
becomes a much bigger job that you end up putting off. Pretty soon you've got an
intractable mess. Roy's room is still always impeccably neat, by the way.
Confidence
In 1955, Dr. Jonas Salk administered his experimental polio vaccine to himself,
his wife, and their three sons. In a newspaper interview, he said that he did it
because he knew it would work. That's courage in action. Where did it come from?
Salk himself said, "It is courage based on confidence, not daring, and it is
confidence based on experience."
At least once or twice during most iterations on our projects, someone sees that
they need to make a radical change to some aspect of the system. When they do, a
bunch of tests break. This is expected. The pair works through the failures one by
one, modifying code to get each test to pass. This could take a few minutes or a few
hours. Invariably, when the pair is integrating the changes one member says, "Wow,
can you imagine how hard this would have been to do without these tests?!"
XP depends on courage, not bravado or reckless daring. Having tests to run to
confirm each change to our code keeps us from being reckless. It lets us proceed
bravely, knowing that we can prove to ourselves that our changes work. Instead of
holding lots of meetings to determine if a change will break something else, we can
just try it, run the tests, and find out. It's hard to be bold in the dark. The tests turn
on the lights.
Tests As Documentation
We have found that well-written tests are less painful to produce than other
forms of documentation. Not only that, they're better.
When you write tests first, you don't have to loop back and write documentation
later. It is an inseparable part of writing the code itself. It's sort of like having a
certain dollar amount each month taken out of your paycheck and put into a 401K.
After a while, you just don't notice it anymore. Any speed we lose in writing tests
first, we more than make up in reduced debugging time and reduced documentation
time. This is a great boost to your team's velocity in and of itself, not to mention the
increased velocity you get from having more confidence.
Even if this weren't true, tests still would be worth the effort. They are better
than any other kind of documentation we've ever seen.
Tests are more detailed than verbal descriptions on paper, without being
cluttered by extra words that describe what the code syntax says. Think about it. The
written code documentation we've seen wastes a lot of space saying things like "The
getMeal(PotPie) method on Shopper asks a Store for a PotPie. It casts this as a Meal
and calls addToBasket(Meal), passing it the Meal…" Why not just look at the code?
When you have a test, you can see a discrete Assertion (in JUnit) that tests this very
behavior and displays a message.
Tests also are more useful than other forms of documentation we've seen. They
give you a scenario in which the behavior of the code should work as intended.
Want to understand what a class does? Look at its tests to see exactly what you
should expect in certain scenarios. Other documentation struggles to do that. It
usually fails, if it tries at all.
Best of all, tests are absolutely up to date all the time (unless you're cheating).
What other documentation can claim that? We remember life before XP. Nine times
out of ten, whenever we walked onto a new project somebody gave us a document
that supposedly described the system we would be working on. It was usually a very
thick binder. As soon as they put this in our hands, they said something like, "This
should help a little, but it's out of date. Come talk to me after you read it." So what
earthly good was that document? Maybe it built character to put it together, but
that's all it was good for.
Not all non-code documentation is bad. When a customer needs a written
document other than code (say, for regulatory approval), you should produce it. XP
simply says you should produce only the written documents that you absolutely
need. The problem is that traditional approaches tend to substitute documentation for
communication, and tend to exaggerate progress with documentation. Producing a
document may get you closer to your goal, but documents don't run. In the end, it's
the code the counts. Alistair Cockburn says:
Written, reviewed requirements and design documents are "promises"
for what will be built, serving as timed progress markers. There are
times when creating them is good. However, a more accurate timed
progress marker is running tested code. It is more accurate because it
is not a timed promise, it is a timed accomplishment. – Alistair
Cockburn in Jim Highsmith, e-business application delivery, Vol. 12,
No. 2, February 2000 [http://cutter.com/ead/ead0002.html]
Tests are the best form of system documentation because they are the form that
distracts least from producing releasable code. Don't settle for less.
How To Write Tests First
Before you write code, think about what it will do. Write a test that will use the
methods you haven't written yet. Assume the methods exist and use them in the test.
The test won't compile (if you have to compile things in your environment). Write
the class to be tested, and its methods. Just a stub, not all the details. Your test
should compile now.
Add the test to the test suite that holds all of your other tests for related stuff.
Run the test suite. Your new test will cause it to fail. You don't have any
implementation for the methods you're testing, so this shouldn't be a surprise.
Running a test just to see it fail might seem a little strange, but it's important. Failure
validates the test at this point. If it passes, it's clearly wrong.
Now write just enough code to get the test to pass when you run the test suite
again. Doing things this way guarantees the smallest design that could possibly
work. It keeps your code simple. Yes, there will be refactoring to do later, but it will
be small.
Add your test suite to the suite of tests for the entire system and run it. That may
seem redundant, but it isn't. A few days before OOPSLA '99, a project he was
heavily involved with was coming to the end of an iteration. He was trying to add a
new feature to the persistence framework. Pairing with someone who was new to the
project, to Java, and to XP, Ken took charge. He coded like a madman for an entire
day, writing tons of code without writing tests first (strike one) and not rerunning the
test suite for the entire persistence framework (strike two). After struggling to get
the new feature to work, he rotated pairs and tried to integrate with a new partner.
They ran the test suite for the persistence framework and got roughly 30 failures.
Thinking out loud, Ken's pair said, "Let's see, they all ran with your changes before
we integrated, right?" Ken felt like and idiot.
Save yourself this pain. Get addicted to running the tests. Made a change? Run
the tests. Made a change that you didn't like and backed it out? Run the tests.
Integrated? Run the tests. Took a break for coffee and just got back to your desk?
Run the tests. You get the point.
Refactor the tests when they don't seem to be giving you the leverage you want.2
If you notice that the suite of tests for a given class doesn't include something that
should be tested, write the new test and run the suite to make sure it passes. If you
need to refactor some portion of the code, and you aren't satisfied that the existing
tests help you (maybe they don't cover everything well enough), refactor the tests
first. Keeping your tests clean is just like keeping your code clean, only more
important. Better tests give you more leverage to make things work better and to add
to new features quickly.
In XP Explored (which should be published by the time you read this), Bill
Wake gives a simple set of steps for what he called the "Test/Code Cycle" in XP:
Write a single test.
Compile it. It shouldn't compile, because you haven't written the
implementation code it calls.
Implement just enough code to get the test to compile.
Run the test and see it fail.
Implement just enough code to get the test to pass.
Refactor for clarity and "once and only once."
Repeat.
Bill claims this process should take about ten minutes per test. If it takes longer,
start writing smaller tests. That may be a bit short, but it's not crazy. In early 2000,
Ward Cunningham stopped by RoleModel Software, Inc. to check out how Ken's
team was implementing XP. He paired with a number of folks on the team. Every
person he paired with made one major observation: Ward took small steps,
sometimes ridiculously small, but he moved like the wind.
Test-first programming is all about building confidence so that you can work at
maximum speed. It only works if you test a lot, which means you have to take steps
pass. Make a change. If the tests fail, the change must have caused it. If you write a
few tests, then code for a couple of days, where is the error when a test fails? You'll
be hunting for a while, which will slow you down. [WHAT'S A GOOD ANALOGY
HERE? SOMETHING ABOUT PROBLEM BUILD-UP…]
What To Test
The rule of thumb we use is to write tests for non-trivial things that could break.
We tend not to write tests for getter and setter methods. We've also learned to shy
away from writing tests for methods that simply invoke another method, as long as
that method already has a test. You'll come up with your own exceptional cases for
when you don't need to write tests.
Err on the side of having too many tests. When in doubt, write one. If you need
the confidence that your getters and setters absolutely will not break, write tests for
them. There aren't hard and fast rules here. Write they tests you need.
Very few of us like writing tests, but we lave having them. It's some extra work,
but it's well worth it. Until you have a bunch of tests and a lot of experience getting
burnt by not having one you need, it's better to have too many.
How To Start Writing Tests First
You should be convinced that you need to write tests first. You might have no
idea how to do it. Relax. You're in good company. Every time we talk with people
who aren't used to writing tests first, we hear things like
How exactly do I write a test first?
How would you write a test first for XYZ?
Huh?
To be honest, most people "in the know" about XP respond roughly the same
way. They say they can show you how to write tests before you write code, but they
can't describe it to you. This is a cop out. This is not a cop out. That was not a typo.
Asking someone how to write tests first is like asking someone how to write
source code. You can't code-by-number. The code you write depends on a host of
variables. Likewise, there isn't a comprehensive set of rules for you to follow when
writing tests. The tests you write will depend on the code you want to build to
exercise the tests.
Unit tests are just another type of source code. You write them, compile them if
you have to, and run them. If you use xUnit3 (and we recommend it), it's just like
writing code that employs a small library of components, methods, or functions. The
only real difference is the goal.
Old habits die hard. If you aren't used to writing tests first, it feels awkward.
Take comfort in knowing that
eventually, it will become as natural as writing source code
your first tests will stink, but that's okay
your tests will improve with practice
even crummy tests are better than none
The key to getting into the habit of writing tests first is to realize that you've
been doing it for years, but you probably didn't know it.
When you write code, you are imagining the tests. You just haven't written them
down yet. If you're writing some code to compute a salary, you're thinking…get the
base salary and bonuses for a given employee from the database…compute FICA…
determine the employee's tax bracket…compute withholding…compute take-home
pay…and so on.
Stop. You already have imagined how the code is supposed to work. The only
thing you have to do now in order to write a test first is to write a test method for the
first step that assumes that step is in the code already. Write a method that calls the
as-yet-unwritten method getEmployeeSalaryData(String employeeName). Give it a
known employeeName and check that the results are what you would expect. The
test will fail, of course, because the method isn't there.
Write the real code for getEmployeeSalaryData(). Run the test again. Fix the
code until it passes all the tests. That's all there is to it.
Some things are harder to test than others (see Testing User Interfaces below).
Sometimes it's hard to imagine the tests first. Keep at it. It will feel more natural in
time.
Testing User Interfaces
Testing user interfaces is royal pain in the backside. We get asked a lot how we
write tests for these things. We have lots of answers, but they all stink. The bottom
line is that the coverage we get from our user interface unit tests seems significantly
lower than what we get from testing our business logic. The value received from the
tests doesn't seem to be worth the effort put into writing them.
The best way we've found to test user interfaces is to isolate what you're testing
first. Separate the UI from the business logic behind it as much as possible. Test the
business logic with unit tests, which make the UI less prone to break. Of course, that
just means there is less to break, not that it's been tested adequately. Try to write unit
tests for what remains in the UI (probably because it belongs there). You probably
won't be able to test everything this way, but that's all right. It's better to have solid
unit tests for 90% of the system than none at all.
One of the best ways we've seen to test user interfaces is to test as much as we
can with unit tests, and then use functional tests to fill in the blanks.
Functional Tests
Functional testing ("acceptance testing" is probably a better term) is actually
more important than unit testing in many ways.
There is no functional testing equivalent of JUnit. You can't just download
something and start testing on day one. Even if you could, you still would need
customers to help define the tests.
Customers often have as much trouble writing functional tests as developers
have writing unit tests. Give them time. Figure out how you can automate these. Run
them nightly. Give your customers the same kind of confidence boost that unit tests
give developers. Without functional tests to prove a customer story "works", it
doesn't exist. It certainly can't ship.
We use a functional testing framework affectionately known as JAccept™. The
customer enter tests into Microsoft Word tables. The tests consist of user actions that
can be performed on the UI being tested. A set of Java classes read the test files each
night (we actually generate HTML from the Word files which the classes then parse)
and run the tests automatically. Results are written to an HTML output file. We're
currently working on porting the entire thing to XML, using Ant as the file
dependency engine, and adding a customized XML editor on the front end.
The way you do functional testing isn't as important as doing it. Functional tests
are the only thing that prove to your customer that the system "works." Without
these, you're telling your customer to trust you. We hope they can, and we hope they
believe they can. Proof removes all doubt. It is the customer's equivalent of the
xUnit green bar. Nothing gives a programmer a shot in the arm quite like seeing that
wonderful green bar. Give your customer the same confidence.
to being "done". This lets your customer make informed decisions about whether
or not a system is ready for release.
Automate functional testing whenever you can. This makes it a normal part of
life. Run them daily. This will give your customers the confidence they need to
remain enthusiastically involved with the project.
[Need to insert some of our Acceptance Tests stories.
What Plans Are
Planning is the way we steer an XP project. We use stories to sketch out where
we would like to go. We defer specifying details for stories until the iteration in
which we'll code them. We make small adjustments as we go.
Planning minimizes your chances of ending up in a ditch, and can help you get
out one when you're in it. Plan like people were said to have voted in Chicago in
1968: early and often.
If you don't have a map you'll get lost. If you never deviate from the map,
you'll probably miss lots of good stuff that is off the beaten path. Thus, we come up
with a plan but we're willing to stray from it.
Paul Grobstein said that the concept of being "right" should be replaced with
that of being "progressively less wrong." The former measures your success or
failure by proximity to a fixed point, a target, set at the beginning. This encourages
people to put on blinders. The latter measures your success or failure by charting
your progress from your starting point. This encourages exploration, respect for experience, and the appreciation of the value of each individual's perspective on a
problem. XP planning is all about learning, and then applying the lessons learned as
soon as possible. We hope to be "progressively less wrong" over time.
we would like to go. We defer specifying details for stories until the iteration in
which we'll code them. We make small adjustments as we go.
Planning minimizes your chances of ending up in a ditch, and can help you get
out one when you're in it. Plan like people were said to have voted in Chicago in
1968: early and often.
If you don't have a map you'll get lost. If you never deviate from the map,
you'll probably miss lots of good stuff that is off the beaten path. Thus, we come up
with a plan but we're willing to stray from it.
Paul Grobstein said that the concept of being "right" should be replaced with
that of being "progressively less wrong." The former measures your success or
failure by proximity to a fixed point, a target, set at the beginning. This encourages
people to put on blinders. The latter measures your success or failure by charting
your progress from your starting point. This encourages exploration, respect for experience, and the appreciation of the value of each individual's perspective on a
problem. XP planning is all about learning, and then applying the lessons learned as
soon as possible. We hope to be "progressively less wrong" over time.
What is Xtreme Programming XP
Extreme Programming (XP) is about social change. It is about letting go of habits and patterns that were adaptive in the past, but now get in the way of us doing our best work. It is about giving up the defenses that protect us but interfere with our productivity. It may leave us feeling exposed.
It is about being open about what we are capable of doing and then doing it. And, allowing and expecting others to do the same. It is about getting past our adolescent surety that "I know better than everyone else and all I need is to be left alone to be the greatest." It is about finding our adult place in the larger world, finding our place in the community including the realm of business/work. It is about the process of becoming more of our best selves and in the process our best as developers. And, it is about writing great code that is really good for business.
Good relationships lead to good business. Productivity and confidence are related to our human relationships in the workplace as well as to our coding or other work activities. You need both technique and good relationships to be successful. XP addresses both.
Prepare for success. Don't protect yourself from success by holding back. Do your best and then deal with the consequences. That's extreme. You leave yourself exposed. For some people that is incredibly scary, for others it's daily life. That is why there are such polarized reactions to XP.
XP is a style of software development focusing on excellent application of programming techniques, clear communication, and teamwork which allows us to accomplish things we previously could not even imagine. XP includes:
A philosophy of software development based on the values of communication, feedback, simplicity, courage, and respect.
A body of practices proven useful in improving software development. The practices complement each other, amplifying their effects. They are chosen as expressions of the values.
A set of complementary principles, intellectual techniques for translating the values into practice, useful when there isn't a practice handy for your particular problem.
A community that shares these values and many of the same practices.
XP is a path of improvement to excellence for people coming together to develop software. It is distinguished from other methodologies by:
Its short development cycles, resulting in early, concrete, and continuing feedback.
Its incremental planning approach, which quickly comes up with an overall plan that is expected to evolve through the life of the project.
Its ability to flexibly schedule the implementation of functionality, responding to changing business needs.
Its reliance on automated tests written by programmers, customers, and testers to monitor the progress of development, to allow the system to evolve, and to catch defects early.
Its reliance on oral communication, tests, and source code to communicate system structure and intent.
Its reliance on an evolutionary design process that lasts as long as the system lasts.
Its reliance on the close collaboration of actively engaged individuals with ordinary talent.
Its reliance on practices that work with both the short-term instincts of the team members and the long-term interests of the project.
Values
Paul, the master gardener, has an intuitive sense of what needs to be done next. He knows in his bones what matters and what doesn't. I might think perfectly straight rows are really important. I put a lot of effort into making my rows straight. Along comes Paul and says, "Why are you working so hard at making the rows straight? What you need is more compost." The difference between what I think is valuable and what is really valuable creates waste.
Everyone who touches software development has a sense of what matters. One person might think what really matters is carefully thinking through all conceivable design decisions before implementing. Another might think what really matters is not having any restrictions on his own personal freedom.
As Will Rogers said, "It ain't what you don't know that gets you in trouble. It's what you know that ain't so." The biggest problem I encounter in what people "just know" about software development is that they are focused on individual action. What actually matters is not how any given person behaves as much as how the individuals behave as part of a team and as part of an organization.
For example, people get passionate about coding style. While there are undoubtedly better styles and worse styles, the most important style issue is that the team chooses to work towards a common style. Idiosyncratic coding styles and the values revealed by them, individual freedom at all costs, don't help the team succeed.
If everyone on the team chooses to focus on what's important to the team, what is it they should focus on? XP embraces five values to guide development: communication, simplicity, feedback, courage, and respect.
Thinking Short
An idealist believes the short run doesn't count. A cynic believes the long run doesn't
matter. A realist believes that what is done or left undone in the short run determines
the long run.
-- Sidney J. Harris
matter. A realist believes that what is done or left undone in the short run determines
the long run.
-- Sidney J. Harris
Keep your iterations short. This minimizes negative surprises and keeps
you on track. Release early and often. This will tell you if the track you
think you should be on is what your users really want. Both short
iterations and small releases reduce your project risk.
Most other software development force people to predict the weather for the
next six months to one year. We don't know about you, but we won't leave our
umbrellas at home if these folks tell us to.
XP takes the opposite approach. We think short. This means two things:
1. develop in short iterations
2. release often
We do everything a little bit every day (remember the rhythm of code a little,
test a little, integrate a little), and we take stock of what we've done at frequent
intervals. That's an iteration. We also release a working system to end users
frequently in order to get real-world feedback on how we're doing.
Short iterations keep a project under control. They provide natural, regular, and
frequent checkpoints for planning. This lets you make small corrections instead of
over steering to try to get out of a skid.
Short iterations also keep the people on the project focused on what counts –
delivering business value to customers. If you don't do this, nothing else matters.
Short releases keep you grounded in reality. There is nothing like feedback from
real users to keep you developing the right system.
Maintaining Control
The United States Air Force Blue Angels squadron of elite pilots tours the world
giving death defying demonstrations of aviation skill. They rarely make a mistake.
When they do, it's catastrophic. In one incident, the entire squadron followed the
lead pilot as he flew into the ground.
The Blue Angels have a special investigative unit that tries to get to bottom of
incidents like this. They look at what they call the "error chain" to figure it out. The
lead pilot lost his focus during the maneuver. He lost his focus because he was tired.
He was tired because his back hurt the night before and he didn't get enough sleep.
His back hurt because he wrenched it playing volleyball a week ago and didn't get
the proper medical attention. The whole squadron died because of one small error
that one person made long before the final catastrophe.
Software projects are like that. The longer you let them go without making small
corrections, the more those small errors snowball. Pretty soon, you're out of control
and the whole squadron flies into the ground.
We said in Chapter 10 that you'll always be wrong about the future. Why is it
that projects continually ignore this reality? The longer you go between
measurements of how you're doing, the more likely you are to crash. Keeping your
iterations short makes this rare (although not impossible). You get feedback on how
you're doing in weeks instead of months. You get it sooner rather than later, while
there's still time to do something about it.
Staying Focused
The longer the time between measurements of where you are, the more pressure
you will feel to make it look like you were right when you predicted the future. If
you predicted a lot over a long period of time, it won't take too long until you are
overwhelmed by all the crises you have to handle and you won't know where to start
fixing them. You'll lose focus because you are worried about spinning the story
about why you weren't really that far off in your predictions.
What if you took stock of where you are every few weeks? If you did that, you
wouldn't be able to afford to lose your focus on delivering business value to your
customers. With only two or three weeks before your next measurement, you don't
have time for distractions. Best of all, you'll be more likely to predict accurately,
because you don't have to predict the weather months in advance. That means you
won't have to waste your time on spin.
You will encounter surprises. Some will be negative. Measuring often
minimizes the number of those surprises and decreases their magnitude. When you
encounter one, you can tackle it and move on. You don't have the false belief that
you can put it off, work on something else, and get back to it before the next
milestone, because the next milestone is only a few days away.
Staying Grounded In Reality
How do you know if you're developing the right system? Ask the users. The
problem with many development methods is that they
assume what users want, or
they ask users what they want at the beginning and assume they knew
what the users meant
Both are dangerous. Either way, you will be wrong. Communication is a tricky
thing, as we discussed in Chapter 10. This is especially true when you are talking to
users who might not know exactly know what they really want. Users rarely know
what they want because they've never seen it. If they had, they probably wouldn't
need you to build software for them. Giving them something to try can help them
imagine what they really need. It's better to get something in their hands to let them
explore, then update and refine constantly.
In his paper Improving Software Quality, Bob Green says,
Until you deliver a program to the client, you have not accomplished
anything, and you haven't started receiving the objective feedback that
will ensure a quality system. The advantage of going after the
immediate problem first is two-fold: it gets the client on your side, and
it uncovers facts about the problem that may make the rest of the
project simpler or unnecessary. – Bob Green, "Improving Software
Quality" (http://www.robelle.com/library/papers/quality/ )
Deliver something. It doesn't have to be complete. It doesn't have to do much at
all. It just has to work. The more often you do this, the more often you get the
feedback you need in order to steer the project toward what users want. You also get
to show your customer that you are making progress toward that goal.
For most systems, you have almost no chance of guessing right about what users
really want. The secret is to guess wrong early and often. Small, frequent releases let
you fail fast and learn from the last failure. The result is a product that is as close to
what users want as you can get.
Think Simply
Roy came to XP from a Big 5 consulting firm that will remain nameless to
protect the guilty. He was used to a methodology that came on a CD…because that's
the only medium it would fit on. On his first day working at Ken's company, Ken
asked him to write a little code for a spike. Roy spent four hours on the problem and
came up with something ridiculously complex, and he had a headache. Seeing his
pain, Ken came over and "helped" him refactor. Within thirty minutes, Ken had an
elegant solution with about one-third the code. Yes, Roy felt like an idiot.
It seems obvious that the simplest solution is probably right, but this has been
forgotten. When you are taking your first steps with XP in the real world, nothing
could be more important. XP is an answer to the question, "How little can we do and
still create great software?".
Simplicity is easier than complexity in the long run. Certainly, coming up with
the simplest thing that could possibly work takes some skill. Most often, though, the
barrier that keeps us from doing this is a predisposition to doing complicated things.
Maybe this makes us feel smarter.
You should be like a child (we know saying this will be held against us forever).
Kids often don't know the complicated way to do something. They just assume the
simple way will work, and they go for it. XP requires you to do the same thing. Just
do it and see if it works. This is especially true when you start.
Try the XP practices and see if they work. If they don't, respond just enough to
make them work. Simple.
protect the guilty. He was used to a methodology that came on a CD…because that's
the only medium it would fit on. On his first day working at Ken's company, Ken
asked him to write a little code for a spike. Roy spent four hours on the problem and
came up with something ridiculously complex, and he had a headache. Seeing his
pain, Ken came over and "helped" him refactor. Within thirty minutes, Ken had an
elegant solution with about one-third the code. Yes, Roy felt like an idiot.
It seems obvious that the simplest solution is probably right, but this has been
forgotten. When you are taking your first steps with XP in the real world, nothing
could be more important. XP is an answer to the question, "How little can we do and
still create great software?".
Simplicity is easier than complexity in the long run. Certainly, coming up with
the simplest thing that could possibly work takes some skill. Most often, though, the
barrier that keeps us from doing this is a predisposition to doing complicated things.
Maybe this makes us feel smarter.
You should be like a child (we know saying this will be held against us forever).
Kids often don't know the complicated way to do something. They just assume the
simple way will work, and they go for it. XP requires you to do the same thing. Just
do it and see if it works. This is especially true when you start.
Try the XP practices and see if they work. If they don't, respond just enough to
make them work. Simple.
The XP Essentials
Arguments about whether or not a given project is actually "doing XP" aren't
productive. All of the practices reinforce each other, so they all are important. But
we like to take a more practical stance here. As heretical as it might sound, there are
certain things you must be doing before other things matter at all. That means certain
XP practices are more important than others when you start. If you don't have these
essentials, the rest of the practices don't matter because you'll probably be hurting in
a way that they won't heal:
1. Planning and estimating
2. Small releases (and iterations)
3. Testing First
4. Pair Programming
5. Refactoring
6. Continuous Integration
You may not get the rest of the project moving with you, but doing these things
on even a subset of your project will get you going in a positive way and soon
people will start noticing the difference.
If you are going to add any of the other XP practices when you get started, fine.
We strongly suggest fasting from any other non-XP practices for at least a month,
and being incredibly cheerful and friendly (which won't be hard if you are really
doing nothing but XP).
Maybe you're saying, "surely, you can't mean every other practice". We still
need to attend the XYZ meetings. And, of course, Sam needs to finish the design
document he has been writing since he is already 70% complete. We also have
gotten pretty good at Microsoft Project for doing our project tracking, so there is no
reason to change direction there. And our team is already divided quite nicely into
the client group and the server group. And, Joe is already the "database king" and
has that part of the system well under control. It wouldn't make sense to have him
start writing tests or pairing with anyone. And…
Nope. We mean everything. Tell whoever you can that you are going to put
everything but the essentials necessary to meet your boss's goals on hold for a while
because of your tight schedule. (We're sure you have one… then there is a lot less
risk in experimenting with XP because you won't be under a microscope). After a
month, if missing something really hurt you, it is not like you left it 50 miles back on
the ice and you can't get it back. But, how will you know how fast you can travel if
you don't unload everything else.
If doing this will get you fired before the month is out, do just enough to not get
fired. You will probably be so productive, that people will start noticing the
productivity and start following your lead.
Remember that project we told you about earlier where Ken took over for
another developer who had a family emergency? Well, when the emergency was
over, Ken and the other developer, Joe (not his real name), overlapped a week in
order to make a smooth transition as he handed back over the reins. On day one of
his return, Joe spent most of the day with Ken to find out what he had done in the
previous five weeks. By mid-day, Joe was quite impressed. "You sure have been
busy while I've been gone." Two days later, Ken hadn't seen Joe other than in
fleeting moments. They had arranged to have dinner together that night. Shortly
into the evening, Ken started the conversation.
"Joe, where have you been the last few days?"
"You know, all those meetings."
"What meetings? You've just been back for a couple of days. What are you
doing in meetings."
"Come to think of it, I've noticed that you don't seem to be in any of those
meetings. How have you managed to avoid them."
"It's simple. Whenever Ralph (the manager, not his real name) asked me if I
could attend a meeting, I'd say, 'Sure, I can attend if you think that's the best use of
my time. You had previously asked me to get [something] done, but if you want me
to push that out, it's your call.'. Most of the time, Ralph would say, 'Ya know, I'm not
really sure if you'll be needed at that meeting. Tell you what. Could you be by the
phone during the time of the meeting? That way, in case I think you're needed, I
could just call you in.'. I'd say, 'I'll be right here, working on [something]. And I'll
be happy to drop it when you call.' He just had never thought about the impact of
productive. All of the practices reinforce each other, so they all are important. But
we like to take a more practical stance here. As heretical as it might sound, there are
certain things you must be doing before other things matter at all. That means certain
XP practices are more important than others when you start. If you don't have these
essentials, the rest of the practices don't matter because you'll probably be hurting in
a way that they won't heal:
1. Planning and estimating
2. Small releases (and iterations)
3. Testing First
4. Pair Programming
5. Refactoring
6. Continuous Integration
You may not get the rest of the project moving with you, but doing these things
on even a subset of your project will get you going in a positive way and soon
people will start noticing the difference.
If you are going to add any of the other XP practices when you get started, fine.
We strongly suggest fasting from any other non-XP practices for at least a month,
and being incredibly cheerful and friendly (which won't be hard if you are really
doing nothing but XP).
Maybe you're saying, "surely, you can't mean every other practice". We still
need to attend the XYZ meetings. And, of course, Sam needs to finish the design
document he has been writing since he is already 70% complete. We also have
gotten pretty good at Microsoft Project for doing our project tracking, so there is no
reason to change direction there. And our team is already divided quite nicely into
the client group and the server group. And, Joe is already the "database king" and
has that part of the system well under control. It wouldn't make sense to have him
start writing tests or pairing with anyone. And…
Nope. We mean everything. Tell whoever you can that you are going to put
everything but the essentials necessary to meet your boss's goals on hold for a while
because of your tight schedule. (We're sure you have one… then there is a lot less
risk in experimenting with XP because you won't be under a microscope). After a
month, if missing something really hurt you, it is not like you left it 50 miles back on
the ice and you can't get it back. But, how will you know how fast you can travel if
you don't unload everything else.
If doing this will get you fired before the month is out, do just enough to not get
fired. You will probably be so productive, that people will start noticing the
productivity and start following your lead.
Remember that project we told you about earlier where Ken took over for
another developer who had a family emergency? Well, when the emergency was
over, Ken and the other developer, Joe (not his real name), overlapped a week in
order to make a smooth transition as he handed back over the reins. On day one of
his return, Joe spent most of the day with Ken to find out what he had done in the
previous five weeks. By mid-day, Joe was quite impressed. "You sure have been
busy while I've been gone." Two days later, Ken hadn't seen Joe other than in
fleeting moments. They had arranged to have dinner together that night. Shortly
into the evening, Ken started the conversation.
"Joe, where have you been the last few days?"
"You know, all those meetings."
"What meetings? You've just been back for a couple of days. What are you
doing in meetings."
"Come to think of it, I've noticed that you don't seem to be in any of those
meetings. How have you managed to avoid them."
"It's simple. Whenever Ralph (the manager, not his real name) asked me if I
could attend a meeting, I'd say, 'Sure, I can attend if you think that's the best use of
my time. You had previously asked me to get [something] done, but if you want me
to push that out, it's your call.'. Most of the time, Ralph would say, 'Ya know, I'm not
really sure if you'll be needed at that meeting. Tell you what. Could you be by the
phone during the time of the meeting? That way, in case I think you're needed, I
could just call you in.'. I'd say, 'I'll be right here, working on [something]. And I'll
be happy to drop it when you call.' He just had never thought about the impact of
those meetings. Every once in a while, he'd say, 'Yeah, I hate to take you away from
that, but I really think you need to be at this one.' So, I'd say, 'Sure thing. If you need
me there, I'll be there.' I think I've attended three formal meetings since I've been
here and I think Ralph likes the results."
"Are you kidding me. He loves you. You've made it hard for me to come back.
I've got some pretty big shoes to fill."
"Nah. You can do it. Just learn how to say, 'I'll be there, if you think it's the best
use of my time.' And make sure your getting good work done in between meetings."
Ken likes to drum a basic software development mantra into people's heads.
"Make it run, make it right, make it fast." These core practices are what it takes to
make XP "run" in your organization. Once you have these in place, you can make it
right by adding the others to get the full, synergistic XP experience. Maybe you will
even find a good reason to add something else you used to do (or some variation of
it). Once all the practices are reinforcing each other, you can refine XP within your
particular context. That's making it fast.
If you make it run first, you will be better equipped to overcome resistance that
you are likely to face when you're trying to make it right and fast.
You can probably get away with "acting weird and being into that XP stuff" for
about a month without getting too much resistance as long as you don't try force it
on everyone else or break commitments to others without permission.
At the end of a month, you should have enough results to begin defending
yourself if attacks come. But more likely, you will find others being interested in
joining you and still others spending their time defending themselves…
Picture this. After asking your manager what he wants most out of you, you are
successfully tackling it with XP and seeing good results. You have a great attitude
toward your boss and your morale is going up and its starting to get contagious.
Your boss has heard about some of the cool side-benefits of having the tests. You
are moving faster than ever (partially because XP is helping you and partially
because you are not doing a lot of other things that are less productive). One of your
resistant colleagues seeks out your boss to complain. You figure it out… he's
complaining that you're playing to win!
The Timeless Way of Programming
The architect Christopher Alexander describes a time not so long ago when people knew how to design and build spaces for themselves, uniquely fitted to their own needs and to their climate and culture. Growing up I heard stories of my carpenter great-grandfather. Whenever his family moved to a new town, he would immediately begin doing odd jobs and saving money. When he had enough, he would buy lumber and build a house. My great-grandfather wasn't trained as an architect, but he knew how to design a house that would suit his family.
Alexander notes that an architect's selfish interests are not aligned with the client's. The architect wants to get the job done quickly and win awards, but is missing critical information: how the client wants to live. Alexander's dream was to return the power of designing space to the people whose lives were most affected by it.
Alexander collected architectural patterns as a means to this end, encoding good solutions to the problems known to recur in designing and building homes. The patterns were never intended as an end in themselves, but as a means of balancing power between professional designers and those who live and work in the space being designed.
Alexander's vision still included a role for architects. Every project has unique problems as well as tediously predictable ones. The key to designing space that is alive is joining the deep understanding of individual preferences and social relationships held by the users of the space with the deep technical understanding of the architect. Bringing these two perspectives together in harmony, with neither dominating the other, enables the design and construction of a space that meets human needs and keeps the rain out too.
As I began to work in software development, I found the same imbalance of power that Alexander fought in architecture. I grew up in Silicon Valley, where engineering was king. "We'll give you what you need even if you don't know you need it," was the often-explicit motto. Software written this way tends to be long on technical virtuosity and short on utility.
With more experience I began to see the opposite imbalance, where business concerns dominated development. Deadlines and scope set only for business reasons do not maintain the integrity of the team. The concerns of users and sponsors are important, but the needs of the developers are also valid. All three need to inform each other.
My bias in writing XP originally was towards the programmers. That's my background. That's who I identified with on teams. However, the past five years have taught me that software development can't be "the programmers and a bunch of other people" if the goal is excellence. Without balance between the concerns of everyone involved, some people will be unable to contribute to development, and their views are important to the team's success. My goal is now to help teams routinely bring technical and business concerns into harmony.
Harmony and balance are the aims of XP. Writing tests is a good thing in itself, but it is only preparation for the bigger task: fostering strong relationships between the diverse people who come together to make money with software. Without a change of heart, all the practices and principles in the world will produce only small, short-term gains. You and the rest of your team share a fate. Act like it and you may come to believe it.
Alexander ultimately failed in his attempt to balance power between the designers and users of space. The architects didn't want to give up any of their power and the clients didn't know to demand any. Programs are not buildings and software development is not construction. Our materials are not their materials and our social structures are not locked into millennia of fixed relationships. We, in software, have the opportunity to create new social structures in which technical excellence is joined with business vision to create new products and services of unique value. This is our advantage.
XP relies on the growth of powerful programmers; able to quickly estimate, implement, and deploy reliable software. These programmers turn over business decision making to the business-oriented part of the team. The appropriate sharing of power and responsibility among the team may seem utopian. This balance is contingent on mutual respect. There is no absolute power. The power of XP evaporates if misused. Each manipulated estimate, each job rushed through without pride, puts the team that much further from its potential power. XP relies on each member of the team; including executives, managers, and customers; to be fully committed and contribute what he can. A team working together can accomplish more than the sum of its members' separate efforts. Sharing power is pragmatic, not idealistic.
Realizing the potential in software requires teamwork. The first fifty years of computing have gone pretty well. I've heard lectures predicting that the next century is the century of biology, not computing. Computing will be relegated to a supporting role. I believe this will be true if software continues business as usual. If our software tools and techniques creep forward, biology will soon overtake software as a driver of social and economic change.
Tools and techniques change often, but they don't change a lot. People, however, change slowly but deeply. The challenge of XP is to encourage deep change, to renew individual values and mutual relationships to give software a seat at the table for the next fifty years. Unleashing the potential of the human spirit will lead to a future for computing that we can't yet imagine.
The Smelly Software
Both the developer and the customer are battered and bloody, if not dead, after
the typical project. And the project delivers sub-par software at best. Usually it's
junk that everyone is at least a little bit ashamed of. In private.
Based on the prevailing way of doing things, this shouldn't be surprising. Scope
got out of hand fast and changing requirements invalidated the original design.
Pretty soon, nobody even remembered the original design anymore. Under the
intense time pressure, developers took all sorts of shortcuts and did all sorts of dumb
things. Remember, they're just trying to survive. Communication broke down, too.
Who had time for meetings or coordination?
In the end, the software they created looks something like a 1975 Ford Pinto
held together with old speaker wire and duct tape. It's a time bomb with no resale
value. And don't slam the doors too hard or stuff falls off. It's full of bugs, or is a
patchwork of fixes commented with "Not sure why this works - DON'T TOUCH!"
It's brittle. Changing it is so risky that developers perform unnatural acts in an
attempt to squeeze new features into spots not made to accept anything new. That's
the only way to avoid new bugs. Management and customers don't understand why
it seems to be so hard to get the new features in for the next release. Now the
pressure is on again.Developers don't want to produce software like this. Customers don't want to
buy and use it either.
the typical project. And the project delivers sub-par software at best. Usually it's
junk that everyone is at least a little bit ashamed of. In private.
Based on the prevailing way of doing things, this shouldn't be surprising. Scope
got out of hand fast and changing requirements invalidated the original design.
Pretty soon, nobody even remembered the original design anymore. Under the
intense time pressure, developers took all sorts of shortcuts and did all sorts of dumb
things. Remember, they're just trying to survive. Communication broke down, too.
Who had time for meetings or coordination?
In the end, the software they created looks something like a 1975 Ford Pinto
held together with old speaker wire and duct tape. It's a time bomb with no resale
value. And don't slam the doors too hard or stuff falls off. It's full of bugs, or is a
patchwork of fixes commented with "Not sure why this works - DON'T TOUCH!"
It's brittle. Changing it is so risky that developers perform unnatural acts in an
attempt to squeeze new features into spots not made to accept anything new. That's
the only way to avoid new bugs. Management and customers don't understand why
it seems to be so hard to get the new features in for the next release. Now the
pressure is on again.Developers don't want to produce software like this. Customers don't want to
buy and use it either.
The Sad Sponsor
Or you may be like the many business people we know who doubt that they'll
ever get quality software delivered on time and within budget. Who can blame you?You ran the numbers before the project started. You did the due diligence that you
were supposed to do. You vetted the numbers with all the right people and there was
a unanimous "go." Everyone was excited about the possibilities. Then reality set in.
Several months into the project, the software team started requesting additional
resources in order to hit the target date. After you reluctantly cut the hoped for
profit, you found out that they doubted they would ship anywhere close to the time
you wanted. And the "minor" functionality changes that some stakeholders
requested produced a groundswell of resistance from the developers who got the
shakes when you asked their supposedly flexible technology to deliver. They seem
to have forgotten that the customer is the one paying their salaries.
You had to ship or you would have blown twice your budget with nothing to
show for it. Even if you did ship, there was still a good chance you would get fired
for incompetence when you couldn't even come close to the incremental profit you
promised. The next release doesn't look any better. Is there any chance you can
survive in this organization? Even if you can, do you want to stick around with your
current reputation?
This is the norm. The best you can hope for is to survive without looking like an
idiot.
ever get quality software delivered on time and within budget. Who can blame you?You ran the numbers before the project started. You did the due diligence that you
were supposed to do. You vetted the numbers with all the right people and there was
a unanimous "go." Everyone was excited about the possibilities. Then reality set in.
Several months into the project, the software team started requesting additional
resources in order to hit the target date. After you reluctantly cut the hoped for
profit, you found out that they doubted they would ship anywhere close to the time
you wanted. And the "minor" functionality changes that some stakeholders
requested produced a groundswell of resistance from the developers who got the
shakes when you asked their supposedly flexible technology to deliver. They seem
to have forgotten that the customer is the one paying their salaries.
You had to ship or you would have blown twice your budget with nothing to
show for it. Even if you did ship, there was still a good chance you would get fired
for incompetence when you couldn't even come close to the incremental profit you
promised. The next release doesn't look any better. Is there any chance you can
survive in this organization? Even if you can, do you want to stick around with your
current reputation?
This is the norm. The best you can hope for is to survive without looking like an
idiot.
The Rules of the Game
Remember the four values of XP: Simplicity, Feedback,
Communication, and Courage. These are the rules of the game when
you're starting out.
When you're starting out, there are a few principles to keep in mind that will
make things much easier. These "rules" are based on the values of XP:
Simplicity
Feedback
Communication
Courage
Communication, and Courage. These are the rules of the game when
you're starting out.
When you're starting out, there are a few principles to keep in mind that will
make things much easier. These "rules" are based on the values of XP:
Simplicity
Feedback
Communication
Courage
The Pitiful Programmer
Thomas Hobbes claimed that life in a state of nature is "…solitary, poor, nasty,
brutish, and short." With a few notable exceptions, the lives of software developers
are the same way. Their most basic needs aren't being met. In a world like that, folks
revert to the natural condition of competing for scarce resources just to survive.
That's all they can do. They certainly can't thrive.
You may be like the many very intelligent and talented programmers we know
who seem to go from one failed project to another. Often, a particular project started
out great, but it went south in a hurry.
It became clear that your leadership made unreasonable promises, and set the
bar too high. The inevitable technical and organizational obstacles sprang up. Scope
crept. Maybe, after Herculean efforts (often at the expense of your family, social
life, and physical or mental health), the project actually produced something. Not
something to be truly proud of, mind you, but something. Equally likely, the project
got cancelled, but that didn't surprise you or anyone else. The warning signs of
impending failure were all over the place and screaming for attention.
This is the norm. Being part of a project that provides an enriching learning
environment, produces something good, and doesn't kill you along the way is a
fantasy, an unattainable dream. You believe success is just luck, and the chances are
too slim to count on. The best you can hope for is to survive without being maimed.
brutish, and short." With a few notable exceptions, the lives of software developers
are the same way. Their most basic needs aren't being met. In a world like that, folks
revert to the natural condition of competing for scarce resources just to survive.
That's all they can do. They certainly can't thrive.
You may be like the many very intelligent and talented programmers we know
who seem to go from one failed project to another. Often, a particular project started
out great, but it went south in a hurry.
It became clear that your leadership made unreasonable promises, and set the
bar too high. The inevitable technical and organizational obstacles sprang up. Scope
crept. Maybe, after Herculean efforts (often at the expense of your family, social
life, and physical or mental health), the project actually produced something. Not
something to be truly proud of, mind you, but something. Equally likely, the project
got cancelled, but that didn't surprise you or anyone else. The warning signs of
impending failure were all over the place and screaming for attention.
This is the norm. Being part of a project that provides an enriching learning
environment, produces something good, and doesn't kill you along the way is a
fantasy, an unattainable dream. You believe success is just luck, and the chances are
too slim to count on. The best you can hope for is to survive without being maimed.
The Methodologists’ Solution
For years, methodologists have told us that the way to clean up the software
mess is to learn from other engineering disciplines, and we have gone along for the
ride. Other engineering disciplines would never accept the sorry state of affairs that
exists in software. If engineers, or even house builders worked this way they'd be
bankrupt in no time flat. Methodologists tell us that we should learn from them.
What do other engineers do? They spend a lot of time gathering requirements to
make sure they understand what the customer wants. Next, they figure out the
needed raw materials and how to assemble them, culminating in some standard
diagram. After reviewing this diagram carefully they approve it and get down to the
business of creating something real. The product undergoes rigorous testing and
inspections to make sure it's acceptable before any end-customer gets hold of it.
They can't afford to miss their estimate by very much, or so the theory goes.
So, the methodologists say, we should build software like civil engineers build
bridges, to pick one example. After all, they've been doing what they do for far
longer than "software" has even been a word. Using their approach will make us
successful. We'd be arrogant and foolish to think it should be done any differently.
As the British say, this is utter tosh. It's bunk. Let that sink in.
mess is to learn from other engineering disciplines, and we have gone along for the
ride. Other engineering disciplines would never accept the sorry state of affairs that
exists in software. If engineers, or even house builders worked this way they'd be
bankrupt in no time flat. Methodologists tell us that we should learn from them.
What do other engineers do? They spend a lot of time gathering requirements to
make sure they understand what the customer wants. Next, they figure out the
needed raw materials and how to assemble them, culminating in some standard
diagram. After reviewing this diagram carefully they approve it and get down to the
business of creating something real. The product undergoes rigorous testing and
inspections to make sure it's acceptable before any end-customer gets hold of it.
They can't afford to miss their estimate by very much, or so the theory goes.
So, the methodologists say, we should build software like civil engineers build
bridges, to pick one example. After all, they've been doing what they do for far
longer than "software" has even been a word. Using their approach will make us
successful. We'd be arrogant and foolish to think it should be done any differently.
As the British say, this is utter tosh. It's bunk. Let that sink in.
The Manager Perspective on Winning
In our experience, there is nothing that overcomes manager resistance like
undeniable progress toward the goals he will be measured by. Find out what these
are and how you can use XP to help him make progress toward these goals. That is
how a manager defines "winning.".
One technique that Ken has used with great success is to start every project by
asking the manager, "What can I do to help you achieve your personal goals?". In
this conversation, you find out what these goals are and you start off on the right
foot with the manager. Then as you present ideas, tie them to the manager's goals.
If you can't figure out how to tie them to the goals, don't introduce them.
This can also work in the middle of a project when there is tension between
manager and developer. Ask for some of the manager's time. He might be
expecting you to dump a bombshell on him. When you start the conversation with,
"I realize I may have been inadvertently working against you and that's not good for
any of us. Please forgive me. I'd like to start with a clean slate. Help me
understand your personal goals so I can figure out how we can work together to
achieve them." Once the manager picks his jaw up off the floor, listen to them.
Every organization is different. That means every manager will be measured by
different standards. But all managers in all organizations are concerned with one
primary objective. They are on a mission to minimize risk.Remember the asymptotic software development cost curve? Managers are
consumed by minimizing the risks to their projects and to their careers implied by
that curve. They don't want to get fired and they don't want to end up with egg on
their faces. Their knee-jerk reaction to new approaches tends to be that they will cost
too much and take too long, both of which increase project risk. When managers
object to XP, risk avoidance is behind it. If you want to be heard, you had better
couch your responses in those terms. Focus on these things:
The money costs of code development and modification
The time cost of code development and modification
Retention of highly skilled developers
These are all synonyms for risk. All of them make the curve asymptotic. If a given
approach does a better job of flattening that curve, it wins.
Here are the most prevalent objections we've heard and how you can address
each by focusing on flattening the curve. The proposed way to address these issues
here are a bit terse. Hopefully the rest of the book will help reinforce the points
made.
undeniable progress toward the goals he will be measured by. Find out what these
are and how you can use XP to help him make progress toward these goals. That is
how a manager defines "winning.".
One technique that Ken has used with great success is to start every project by
asking the manager, "What can I do to help you achieve your personal goals?". In
this conversation, you find out what these goals are and you start off on the right
foot with the manager. Then as you present ideas, tie them to the manager's goals.
If you can't figure out how to tie them to the goals, don't introduce them.
This can also work in the middle of a project when there is tension between
manager and developer. Ask for some of the manager's time. He might be
expecting you to dump a bombshell on him. When you start the conversation with,
"I realize I may have been inadvertently working against you and that's not good for
any of us. Please forgive me. I'd like to start with a clean slate. Help me
understand your personal goals so I can figure out how we can work together to
achieve them." Once the manager picks his jaw up off the floor, listen to them.
Every organization is different. That means every manager will be measured by
different standards. But all managers in all organizations are concerned with one
primary objective. They are on a mission to minimize risk.Remember the asymptotic software development cost curve? Managers are
consumed by minimizing the risks to their projects and to their careers implied by
that curve. They don't want to get fired and they don't want to end up with egg on
their faces. Their knee-jerk reaction to new approaches tends to be that they will cost
too much and take too long, both of which increase project risk. When managers
object to XP, risk avoidance is behind it. If you want to be heard, you had better
couch your responses in those terms. Focus on these things:
The money costs of code development and modification
The time cost of code development and modification
Retention of highly skilled developers
These are all synonyms for risk. All of them make the curve asymptotic. If a given
approach does a better job of flattening that curve, it wins.
Here are the most prevalent objections we've heard and how you can address
each by focusing on flattening the curve. The proposed way to address these issues
here are a bit terse. Hopefully the rest of the book will help reinforce the points
made.
The Developer Perspective On Winning
In our experience, there is nothing that overcomes developer resistance like
focusing on the environment fostered by XP. Use the geek gene to your advantage.
Developers care about stuff like this:
They want to develop software, not write documentation or spend all day in
meetings.
They want to be proud of the software they develop.
They want to have fun doing their jobs, not feel like they are undergoing
surgery without anesthetic.
Once the software is "released," they don't want to get stuck maintaining it
forever, or go through hell to change it when they have to. They want new
challenges, not just the same old challenge of having to figure out what
unnatural act they can perform to patch the old code.
These are the opposite of what is true when you have a steep cost curve. Unlike
managers, developers don't particularly care about a flat cost curve. They do care
about the pain associated with a steep one. Having an environment that avoids that
pain is how developers define "winning." If you want to be heard, you had better
couch your responses in those terms. If a given approach does a better job of
producing that environment, it beats all comers.
Here are the most common objections and how you can address each by
focusing on results that matter to developers. Again, the proposed ways to address
these issues here are a bit terse. Hopefully the rest of the book will help reinforce
the points made.
focusing on the environment fostered by XP. Use the geek gene to your advantage.
Developers care about stuff like this:
They want to develop software, not write documentation or spend all day in
meetings.
They want to be proud of the software they develop.
They want to have fun doing their jobs, not feel like they are undergoing
surgery without anesthetic.
Once the software is "released," they don't want to get stuck maintaining it
forever, or go through hell to change it when they have to. They want new
challenges, not just the same old challenge of having to figure out what
unnatural act they can perform to patch the old code.
These are the opposite of what is true when you have a steep cost curve. Unlike
managers, developers don't particularly care about a flat cost curve. They do care
about the pain associated with a steep one. Having an environment that avoids that
pain is how developers define "winning." If you want to be heard, you had better
couch your responses in those terms. If a given approach does a better job of
producing that environment, it beats all comers.
Here are the most common objections and how you can address each by
focusing on results that matter to developers. Again, the proposed ways to address
these issues here are a bit terse. Hopefully the rest of the book will help reinforce
the points made.
The Bare Essentials
SOMETHING ABOUT FIRST THINGS FIRST OR TRAVELING LIGHT
--
Nail down the essential XP practices first. Without these, the others
don't matter. If you get them, that will set the stage for implementing
all of the others.
Ernest Shackleton led the British Trans-Antarctic Expedition in 1914. At the
time, he was one of the most experienced Antarctic explorers in the world. He
prepared as well as could be expected. He took 27 men with him.
Within a year of leaving England, their ship Endurance was locked in the ice in
the Weddell Sea north of Antarctica. The pack crushed Endurance slowly over a
period of several months. Before it sank, the men salvaged as much material as they
possibly could and took to the ice. Shackleton knew that they would have to spend
an indefinite period of time living on the floes. There was only one thing to do.
Shackleton gathered everyone for a somber stand-up meeting. He told his men
that they were going to walk out of there alive. To do that, they could carry only
what they absolutely needed – the bare essentials. That meant only two pounds of
"personal gear." When he finished speaking, he took out his gold cigarette case and
several gold sovereigns, and without hesitation dropped them on the ice in the
middle of the circle of men. They all followed suit. Coming out alive was more
important than ultimately worthless baubles. The amazing ending to the story is that
not a single man perished. They not only survived, they won.
--
Nail down the essential XP practices first. Without these, the others
don't matter. If you get them, that will set the stage for implementing
all of the others.
Ernest Shackleton led the British Trans-Antarctic Expedition in 1914. At the
time, he was one of the most experienced Antarctic explorers in the world. He
prepared as well as could be expected. He took 27 men with him.
Within a year of leaving England, their ship Endurance was locked in the ice in
the Weddell Sea north of Antarctica. The pack crushed Endurance slowly over a
period of several months. Before it sank, the men salvaged as much material as they
possibly could and took to the ice. Shackleton knew that they would have to spend
an indefinite period of time living on the floes. There was only one thing to do.
Shackleton gathered everyone for a somber stand-up meeting. He told his men
that they were going to walk out of there alive. To do that, they could carry only
what they absolutely needed – the bare essentials. That meant only two pounds of
"personal gear." When he finished speaking, he took out his gold cigarette case and
several gold sovereigns, and without hesitation dropped them on the ice in the
middle of the circle of men. They all followed suit. Coming out alive was more
important than ultimately worthless baubles. The amazing ending to the story is that
not a single man perished. They not only survived, they won.
Nothing brings what really matters into focus quite like staring death in the eye.
Conducting a software project is no different. Don't believe it? Consider these
sobering statistics from 8,380 software projects in a variety of industries in 19962:
31.1% of projects were cancelled
52.7% were completed but were over budget, over time, or had fewer
features than originally specified
52.7% of projects that broke their budgets cost 189% of their original
estimates
16.2% were on time and under budget
That's as daunting as facing death on the Antarctic ice. Surviving and winning
require that you follow a principle of XP. You have to travel light. When you begin
the XP adventure, you can't carry worthless baubles with you.
So, the first thing you do is meet with your manager (this is true whether you are
a manager or a developer… unless you are the big cheese, you have somebody you
are working for). You say to them something like this:
"I've been examining the way I've been working and I think I could be doing a
better job of helping you meet your goals. In order to do a better job for you, I need
to be perfectly clear on what it is your goals are and what you want me to produce. I
mean the big picture, not necessarily what you want me to produce this week
(although I'd be happy to do that, too). Once I'm clear on that I want to examine
everything I'm doing and make sure that I'm making the best use of my time in order
to help you meet your goals."
After he picks his jaw up off the floor, he'll probably tell you something like:
"Well, we really need to get this product out (or at least to system test, or ready
for the trade show, or…)".
He might also add something like:
"And, you know, I'm really under a lot of pressure from my boss about keeping
Archibald in Marketing happy. So be sensitive to that."
We will almost guarantee you the first words out of their mouths won't be
"attend as many meetings as possible and produce lots of documents that nobody
reads." So, go ahead and ask them. Once they tell you what they want, hold them
accountable to it. Whenever they ask you to do something that seems contrary to the
goals, ask them whether that has become more important than meeting the originally
stated goals. If they say yes, don't be a jerk, gladly do what they ask you to do. If it
becomes a habit, find a good time to talk to them about it.
Nine times out of ten, when you ask your management what they want most
from you and they see you sincerely trying to give it to them, they'll be thrilled.
We've both managed people. Trust us. Starting here, two out of two managers
surveyed want nothing more from their employees. You'll have to sample the other
eight yourself. If you work for one that says otherwise, you might want to seriously
consider looking for a new manager.
Now, all that's left to do is start doing the essential practices of XP on whatever
part of the project you can and be sensitive to his other pressures (hopefully he didn't
dump too many of them on you).
The Art of Estimation
The bedrock of planning is estimating how long work will take. Stories and
tasks are great, but eventually the rubber has to meet the road. Estimation is a
strange thing. It's guessing based on our experience. The more experience you have
in a given context, the better your estimates will be. If we've done exactly the same
thing before on the same project, we use what Beck and Fowler call "Yesterday's
Weather" to make our estimates (that is, we just assume the same estimate this time
around). If we haven't, we look for similar experiences on the same project and
estimate from them. Only as a last resort do we just guess.
That said, estimation can be tough. This is especially true when people are
working with new technologies and/or in new environments. Tell people to keep it
simple. Break stories down into very small tasks (remember the guideline of 0.25 to
two days we mentioned in The Iteration Planning Game). If the sum of the days for
the tasks in a story add up to longer than a week or so, have your customer split the
story. This exercise will help people do a better job at two things:
1. breaking down stories to make sure they know what will and won't be
accomplished
you will improve with practice. On a recent project, Ralph Johnson made the
astute observation, "There is nothing that you can't do better the more you do it."
Your estimates won't ever be perfect, but you can hone your skills. Before you
know it, people will start to take your estimates and plans seriously as they get
closer and closer to reality.
What's Velocity?
Estimating is the art of determining how big some effort is. That's not worth
much unless you also can tell your customer when they'll get it. That's velocity.
Velocity tells you how fast your team can produce the stories required by your
customers in a single iteration.3 The Planning Game and the Iteration Planning
Game tell you how much everything costs. The Tracker or the Coach or the Manager
then specifies the velocity of the team, based on past performance. No other basis
makes sense. Beck and Fowler describe this as "Yesterday's Weather": assume new
stuff that's like stuff you've already done will take just as long to do. If your team
delivered seven stories in the last iteration, assume they'll do the same the next time
around. It's that simple.
There are several ways to express velocity, but they all answer the same
question: how much can your team get done in a single iteration? The two major
candidates appear to be these:
ideal days
some sort of "story points"
The reason these sound different is that they are based on different inputs. The
ideal days form says that your team can produce a certain number of ideal days'
worth of stuff in an iteration's worth of calendar days. The "story points" approach
says that your team can produce a certain number of points (a simple way to express
"bigness", or difficulty) in a single iteration. Six of one, half-dozen of the other,
really. Pick one and go with it.
tasks are great, but eventually the rubber has to meet the road. Estimation is a
strange thing. It's guessing based on our experience. The more experience you have
in a given context, the better your estimates will be. If we've done exactly the same
thing before on the same project, we use what Beck and Fowler call "Yesterday's
Weather" to make our estimates (that is, we just assume the same estimate this time
around). If we haven't, we look for similar experiences on the same project and
estimate from them. Only as a last resort do we just guess.
That said, estimation can be tough. This is especially true when people are
working with new technologies and/or in new environments. Tell people to keep it
simple. Break stories down into very small tasks (remember the guideline of 0.25 to
two days we mentioned in The Iteration Planning Game). If the sum of the days for
the tasks in a story add up to longer than a week or so, have your customer split the
story. This exercise will help people do a better job at two things:
1. breaking down stories to make sure they know what will and won't be
accomplished
you will improve with practice. On a recent project, Ralph Johnson made the
astute observation, "There is nothing that you can't do better the more you do it."
Your estimates won't ever be perfect, but you can hone your skills. Before you
know it, people will start to take your estimates and plans seriously as they get
closer and closer to reality.
What's Velocity?
Estimating is the art of determining how big some effort is. That's not worth
much unless you also can tell your customer when they'll get it. That's velocity.
Velocity tells you how fast your team can produce the stories required by your
customers in a single iteration.3 The Planning Game and the Iteration Planning
Game tell you how much everything costs. The Tracker or the Coach or the Manager
then specifies the velocity of the team, based on past performance. No other basis
makes sense. Beck and Fowler describe this as "Yesterday's Weather": assume new
stuff that's like stuff you've already done will take just as long to do. If your team
delivered seven stories in the last iteration, assume they'll do the same the next time
around. It's that simple.
There are several ways to express velocity, but they all answer the same
question: how much can your team get done in a single iteration? The two major
candidates appear to be these:
ideal days
some sort of "story points"
The reason these sound different is that they are based on different inputs. The
ideal days form says that your team can produce a certain number of ideal days'
worth of stuff in an iteration's worth of calendar days. The "story points" approach
says that your team can produce a certain number of points (a simple way to express
"bigness", or difficulty) in a single iteration. Six of one, half-dozen of the other,
really. Pick one and go with it.
We express velocity in terms of deliverable units per iteration (DUPI), which is
our version of story points. As we said earlier in The Planning Game, each
deliverable unit is about one-half a week of ideal days for one developer. No story
may span more than what a single developer could do in an iteration. We assume a
load factor of 2.5. That's our starting point for all projects. We can adjust up or
down based on the individual project, once we have some experience in that
environment.Given those inputs, each developer can handle roughly 8 DUPI in a
four-week iteration, or 6 in a three-week iteration
This approach standardizes our measurements. The size of each story is a
multiple of a known quantity. There's lots of ways to express it:a single deliverable
unit, an ideal day, or "about half a person week". Load factor can vary by person, but
we usually state velocity in terms of the team as a whole. We tell the customer our
collective velocity: for example, 32DUPIs per iteration. When we start an iteration
we figure out how many days of the iteration each developer is expected to be
present, take into account other distractions they'll have to adjust their individual
load factor, and total up the days we expect that iteration. Here is an example:
Developer Days Available Load Factor Deliverable Units
Joe 15 2.5 6
Nathaniel 18 2.5 7
Ken 10 2.5 4
Amy 19 4 5
Duff 16 2.5 6
Donna 20 3 7
Totals 35
When we estimate, one of us throws out a number of ideal days for a story, we
discuss it a bit and put a number up. If the stories add up to more than the available
days, we cut some out
Beck talked about "load factor" in XP Explained. Load factor is the multiple you
use to get from ideal programming days to calendar days. If you can get eight ideal
days of work done in a 20-day iteration (4 weeks), your load factor is 2.5 (8 / 20). In
Planning XP, Beck and Martin forsook load factor somewhat, and claimed velocity
is the only measure you need. We tend to agree, but we think it's nice to be able to
derive both, just in case you have to estimate how long a short-term project will
take.
Estimation Rules?
Bill Wake says 1/3 story per week per developer and tasks should be less than 3
days . Ken says estimate a load factor… it's not that complicated. Kent says "use
yesterday's weather"? What's best?
You just gotta find something that works for you and recognize that "estimation"
will NEVER give "exact predictions".
Sweet Freedom
We think disciplining ourselves to be honest and humble is worth doing for its
own sake. But even if you're not into character building like that, developing
honesty and humility is great. They give you the freedom to maximize your
potential.
Here is a stereotypical discussion between a developer and a customer in a
"traditional environment":
CUSTOMER: "I want everything yesterday, and I don't care if it kills all of your
people to get it done!" (we're paraphrasing, of course)
DEVELOPER: "Well, that's a lot of stuff. Do you really need it all? Isn't there some
subset that's more important that we could focus on first?"
CUSTOMER: "It's all critical. If we don't get it all, my butt's in a sling."
own sake. But even if you're not into character building like that, developing
honesty and humility is great. They give you the freedom to maximize your
potential.
Here is a stereotypical discussion between a developer and a customer in a
"traditional environment":
CUSTOMER: "I want everything yesterday, and I don't care if it kills all of your
people to get it done!" (we're paraphrasing, of course)
DEVELOPER: "Well, that's a lot of stuff. Do you really need it all? Isn't there some
subset that's more important that we could focus on first?"
CUSTOMER: "It's all critical. If we don't get it all, my butt's in a sling."
DEVELOPER: "I hear you. We are in this together. We'll get it done. You can count
on us."
A month later:
CUSTOMER: "You didn't deliver! I want this stuff now!!"
DEVELOPER: "There were some unexpected speed bumps. But I hear you loud and
clear. We are in this together. We'll get it done. You can count on us."
Uh…this is rubbish. The customer is lying to the developer. Not everything is a
number-one priority; that's being lazy. The developer is lying to the customer, too.
He's committing to something that's ludicrous, and he's doing it with a straight face.
When he fails (no surprise, really), he learns nothing and makes the same stupid
promise again. The customer acts like he believes him. It's like a big game of
charades.
What if it went like this instead?
CUSTOMER: "I know I can't have everything right now. I really don't need it. What
I really need is Feature C. Everything else can wait, but we've got to
have Feature C ASAP."
DEVELOPER: "Hmm. We have Feature B in this iteration already, and there isn't
enough room for Feature C on top of it. Should be push Feature B off
and do Feature C first?"
CUSTOMER: "Yep. That will give us what we need."
DEVELOPER: "Okay. Feature C it is. It's about the same estimate as Feature B, so
it's an even trade. We'll get it done."
At the end of the iteration:
CUSTOMER: "Feature C works great! All the acceptance tests pass, so it's exactly
what we were expecting. Can we get Feature B in the next iteration?"
DEVELOPER: "No problem. The next iteration used to have Feature C, Feature F,
and Feature G, based on the original priority order. Feature C isn't
there anymore, and it was the same size as Feature B, so we'll just do
Feature B in the upcoming iteration. We'll get it done."
CUSTOMER: "I know. You have for the last four iterations."
That is honesty and humility in action. Which scenario would you prefer? We
prefer to be free to tell the truth. If everybody expects this, and does it, everybody
wins. If either side doesn't, you will crash and burn.
Come on! You say. Isn't that a bit contrived? Here's a real one from a few days
ago:
We're not very far away from a release date, and people are under a lot of
pressure:
CUSTOMER: "I know you just got the relative date thing working by typing in a
plus or minus followed by a number, but I'd really like to be able to
specify today by typing in a zero."
DEVELOPER: "That's not going to happen. You said you wanted a plus or minus.
That would be a new requirment and it would push the end date out."
CUSTOMER: (angrily) "Don't tell me that's what I wanted! I wanted a zero from the
beginning and you talked me into the plus or minus because you said
it would be easier to do."
DEVELOPER: "Calm down. I'm sorry I used my words poorly. It wasn't what you
wanted it was what you agreed to."
CUSTOMER "OK. It's what I agreed to. Don't tell me it's what I wanted."
DEVELOPER "Again. I'm sorry. I should have said it was what you agreed to."
CUSTOMER "Well, how much longer would it take to make it work with a zero."
DEVELOPER "Well, let's talk about it calmly. OK? (pause) I don't remember what I
told you originally. The issue was that a t for today or a y for
yesterday wouldn't work for internationalization. A zero would work
theoretically, but it's ambiguous could be interpreted as the beginning
of a valid date. As soon as you type a plus or a minus, there is no
confusion and we can shift into relative mode. That date widget we
are using from the 3rd party has some really raunchy code and it wasn't
easy to get it to work with the plus and minus, but writing our own
date widget at this point would be foolish. I don't think it will be
difficult for users to get used to typing a plus or minus for today even
though it isn't intuitively obvious. Of course, either is plus or minus
for that matter. We're going to have to teach them to use them, so I
don't see that it will be more than one sentence in the user manual to
teach them how to use plus-zero, minus-zero, or just plus or minus to
get today."
CUSTOMER "Well, maybe not. But how much would it cost to make it work only
when you type a single zero and tab out of there."
DEVELOPER "Well, now that I've been in the code and pretty much figured it out, it
might be a little easier. But, this isn't the same as keying off a plus or
minus because when you type in a zero, you don't want to switch to
relative mode. If you wanted a t or some other character that wasn't a
number, that would be a piece of cake and I could do it for you right
now. But I can't think of any other characters that would be more
intuitively obvious that wouldn't cause problems for
internationalization. There's also a lot of hairy testing to make sure it
works for all the ways you can get to the point of one zero followed
by a tab. I don't think it would take more than a day, but I'm not so
sure there won't be some other gotchas in there."
CUSTOMER "Hmmm… I still think I want the zero, but I'm not sure."
DEVELOPER "Well, we'll just leave it out for now. If you are sure you want it, let
us know and we'll put it back into the remaining list of things that still
need to be done."
It wasn't perfectly smooth, but brutal honesty got us to the point of reality.
Would "Yes Ma'am, the customer is always right" have gotten us a better result?
Maybe it would have been better if the customer said, "Look here, it shouldn't take
you more than a couple of minutes to make it work with the zero. So make it
work!". If you think that's a better way to work, please don't apply to RoleModel
Software for a job or to hire us to write your software.
It's not just about honesty and humility between a customer and developer.
Think about interaction within a development team. Here is a stereotypical exchange
at a development status meeting where bravado and deceit are rampant:
BOB: "The Humphsplat class was a mess so I completely overhauled it to use
different methods on DinkyDoo. It's much cleaner now. I had to change
the public interface a bit, but it shouldn't be too much trouble, so I went
ahead and migrated it to Integration Test."
JANE: "I'm depending on that class! You should have told me you were going to
do that. Now my stuff won't work!"
BOB: (out loud if he's really brash, to himself if not) "You're always saying that.
You don't want to do it right, so you leave junky code around. Just
implement the changes and get on with it!"
JANE: "I can't get my current list of stuff done and upgrade to your new class.
Unless you'd like to take on some of my tasks?"
BOB: "No, thank you very much. I've got plenty to do already."
FRANK: "I'd love to help out, but I'm really having trouble understanding that part
of the system. The logic seems really complex. Can either of you walk me
through it? I'm sure it would help because I need to add logging to the
DinkyDoo class."
BOB: "The logic is complex because some people don't make it elegant like they
should. I would walk you through it, but all my time is booked cleaning up
other messes."
JANE: "I'd love to, Frank. But now, thanks to Mr. Senior Guru here, I've got too
much work to do to take the time to explain it to you, much less get a good
night's sleep."
And so on. Nobody is communicating with anyone. No problems, interpersonal
or otherwise, have been solved. Everyone is defensive, caught off-guard, or
continually ignorant without any hope of catching up. After the meeting, everyone
returns to their cubes and gets deeper into the jungle without an escape plan.
What if it went like this instead? At the daily stand-up meeting on Tuesday:
BOB: "The Humphsplat class was a mess so Jane and I paired on that yesterday.
We refactored it completely and it's much cleaner now. All the tests pass
on the integration machine, so we're integrated and everyone else should
be fine."
JANE: "That refactoring was tough, but I learned a ton. I understand how
Humphsplat fits into the world now. Bob almost hammered the public
interface, but I caught him and we worked through it."
Bob and I are done with that, so I'm available to pair."
BOB: "Hey! Well…yeah…I was going to…never mind. It was really stupid. I'm
an idiot! But all the tests pass, so I guess I recovered gracefully. Thanks to
Jane, that is."
JANE: "I better watch out or I'll get a big head. I wasn't that brilliant. Bob taught
me a few tricks that I didn't know. Anyway, he and I are done with that
stuff and I'm available to pair."
FRANK: "I'm really having trouble understanding that part of the system. The logic
seems really complex. Can either of you walk me through it? I think it
will help me with my next task. I have to add logging to the DinkyDoo
class."
JANE: "Sure. I understand it now. I can walk you through that first and then we
can pair on your next task."
Again, which scenario would you prefer? We prefer a supportive environment
where everybody is learning, no one gets left behind, and nobody is a prima donna
no matter how talented they are. If you have an environment like this, you feel like
you can do anything. If you don't, prepare for battle.
When you're honest with others and with yourself, you have no choice but to be
humble. When you are humble, you are teachable. When you are teachable, you
learn. When you learn, you can use what you learn to achieve great things. That's
winning.
Subscribe to:
Posts (Atom)