schemes for handling exceptions before you encounter them. When they
come up, handle them as simply as possible.
People who have difficulty believing XP will work often list off a bunch of
exceptions:
How do you pair if you have an odd number of developers?
What if the customer won't write stories?
What if the customer won't write acceptance tests?
What if management refuses to set realistic delivery schedules?
What if management doesn't believe your estimates?
What if management refuses to let you pair program?
What if the cost of tea in China doubles?
How do you handle these proposed exceptions without just ignoring them?
Ignore them until they can't be ignored. Then handle them as simply as possible.
That is the simplest thing that could possibly work.
Handling XP Exceptions Like Code Exceptions
Writing code is easier if you can count on the methods you are using not to
throw exceptions. You can just invoke the method and expect a certain result. This
lets you proceed with confidence. In fact, we have found that programming goes
better when we assume exceptions don't exist. We find out soon enough if we're
wrong. Then we handle the exception with the simplest approach that could possibly
work. That almost always works.
If we went to the other extreme, we would be afraid to write any code until we
knew how to handle all of the possible exceptions, and all of the exceptions in our
exception handlers. This is paranoia. That way lies madness.
Implementing XP in an organization that's not used to it is the same. Assume
there aren't any exceptions to handle. The practices of XP are simple, although not
always easy. It has been called a "lightweight methodology" because none of the
practices requires a lot of ceremony or training. Each is simple to implement and
gives the results it advertises. Assume they work.
When you find an exception, handle it as simply as possible without turning it
into something completely different that misses the point. Don't come up with an
elaborate scheme of exception handling that turns XP in a heavyweight
methodology. Just handle the exception and figure out the best way to keep an
exception, rather than a rule.
Building Sidewalks (THIS DOESN'T REALLY FIT HERE,
SHOULD BE EARLIER IN THE BOOK WHEN WE TALK
ABOUT BDUF – XP IS LIKE BUILDING SIDEWALKS!)
Roy's father has a theory about building sidewalks (he's a little odd this way).
He says that you shouldn't build any until you know where they should go.
Construct your building first. Let people walk around among them for a couple
months. Then build sidewalks where people have worn paths in the grass, no matter
how unorthodox your sidewalk pattern looks. Those sidewalks will be used.
Do the simplest thing that could possibly work. Start with the essentials and do
XP as prescribed. When you can't, handle the exceptions as simply as possible.
Here are just a few exception handling routines we've used:
The OddNumberOfDevelopers Exception
On one of the first "pair programming" days at our first big XP client, we had an
odd number of people. Well, if all production code has to have two sets of eyes on
them, the solution is NOT to let someone write code by themselves. So, we tried a
couple of things. We tri-programmed for awhile. It was OK for a while. To some
of the newbies, every line of code was new and exciting. But after a while, that got
old. So, Ken let the two newbies continue on their own, and he went to check on the
other pair. They were doing fine, so Ken went and read the manual which described
the protocol that was going to come in the serial port.
(You don't need to pair-read, although we have found times that two people
reading similar things in parallel provide some benefits).
When Ken had a clue about where to start on the SerialPort task, it was almost
3:00, and one of the developers had to go pick up her daughter at her day care
center. Imagine that, one pair stopped what they were doing and another one
formed. Cool.
There have been times when the hard part of a problem is solved, and both
developers in the pair know exactly what's going on. One party gets interrupted by
someone else or by nature. The other developer might take the next few steps
without him. When the partner gets back, they are shown what's happened. If they
went too far, they have to undo it. If not, move on. Excuse us for being practical.
Does this ever backfire? Absolutely.
One day, Ken and Duff were pairing together. During the day, their pair was
interrupted four times. It went something like this.
Ken was pulled away for a couple of minutes. A few minutes later, he came
back and took the keyboard. Within moments, he was confused. A method he was
trying to call on wasn't there. He knew it was supposed to be there, he had just
written it earlier that day. He was speechless. Duff said, "what are you looking
for?". Ken said, there was a method called something like [xyz] that I was counting
on. Duff said, "I deleted it.". "Why?". "Nobody was calling on it except the test, so it
wasn't necessary." "Yes, it was. I put it there yesterday as the first part of this task
because I knew I needed it in order to make this task work." "OOPS. Man, you leave
me alone for two minutes, and we've just lost ten mimutes."
An hour later or so, Duff went off to relieve his bladder and Ken browsed a
couple of methods looking for one that they might be able to use when he was
rejoined by Duff. During his browsing, he noticed some superfluous code in one of
the methods, so he changed it. Duff returned and they finished their task. All the
tests in the related test suite passed. Ken suggested they integrate. Duff said, "before
we do, let's run this other test suite which is kind of related, just in case we broke
anything." Ken said, "Nah, we didn't touch anything there that would have affected
it." Duff said, "Well, just humor me." ARRGGGHHH! A red bar! Duff
incredulously states, "The [blah] test. How could that have failed?". Ken sheepishly
responded, "I think I know…".
Similar scenarios happened two more times that day. We went four for four. It
was quite comical. Have we stopped doing little snippets of code when we are
interrupted? No. But we are a little more mindful of showing each other what we did
while the other was away.
Most of the time when you have an odd number of people, there is something
that can safely be done by one person. When that person is ready to roll, it is often
possible that another person can find something safe to do as an individual. If not,
think of something. If not, tri-program for a little while.
As long as pairing is the rule, and exceptions are few and far between, you'll be
fine. In fact, the problems that come up when you make too many exceptions will
become obvious, and you'll discover your own limits as long as you are honest and
humble.
Get over it. Play to win!
The CustomerWontWriteStories Exception
The customer at one of our client's site has a tough time, for some reason,
picking up a pencil or keyboard and writing stories. However, they don't have any
problem telling us what they want. So, they tell us what they want. We write down
what we think we heard and ask them to verify it. (In many ways, that works better,
because we know we understand what we wrote). This is nothing to panic about.
We need user stories. They won't write them down. The simplest thing that could
possibly work is that we write them down based on their input.
If you can get the user to verify the stories, you end up with roughly the same
results. The point is that the customer is still the one identifying the business
requirement and setting the priorities. They just had an assistant which happened to
be you.
Get over it. Play to win!
The CustomerWontWriteAcceptanceTests
Exception
See the CustomerWontWriteStories exception.
If you can get the user to write the acceptance tests, do your best to write them
and get them to verify them. By verifying them, they are signing off on them. If
they refuse to verify them and won't offer you an alternative, they've indirectly
verified them. Eventually the truth will come out and somebody will try to fix it. If
not… Hey, at least you've got some set of tests you can run to verify you are actually
building something. It's better than you had before XP.
Get over it. Play to win!
The ManagementSetsUnrealisticSchedules
Exception
Tell them that you don't think its possible, and give them a date/scope that is
possible. In the meantime, tell them you'll do what you can reasonably do to meet
their schedule. The more realistic schedule will come closer to matching reality.
The big concern here is that they blame XP for missing the schedule. One
strategy is to ask them what they expect to get done in the next month. Estimate
how long you think it will take to get those items done by breaking them into small
chunks, just as you'd do with XP. Do what you can their way, and size how much
they are off by. Then, point out the discrepancy and ask if you can try a different
approach for the next month.
As long as they offer unrealistic schedules, reality will keep hitting them in the
face. Eventually they'll either
a) get the hang of it and stop setting schedules that way, or
b) they'll lose their job, or
c) you'll lose your job, or
d) nothing will happen.
The only bummer out of this is C. And you can look at that as a blessing or at
least as something you might not have avoided if you never tried XP.
On A, B, or D you can run the project according to the more realistic schedule
you set. A is certainly the best situation to be in. On B, you might get new
management that is just as bad, but you might not, and at least you have a fresh start.
On D, you are probably in one of those organizations that have no accountability.
Personally, I'd look for another one because it shows that people either aren't honest
or aren't competent. Another alternative might be to take advantage of it and do the
job well (i.e. play to win!) and stand out as some of the few people who actually do
what they say they are going to do. Maybe others will follow. At least you can
sleep well at night in your integrity.
Get over it. Play to win!
The ManagementDoesntLikeMyEstimates
Exception
Ask them if they know something you don't that will help you get it done
quicker? If they do, great. If not, tell them you are sticking by them and tracking
them. You would be delighted to find out that you were too conservative.
Otherwise, see the ManagementSetsUnrealisticSchedules exception.
The MyManagementWontLetMePair Exception
This is one of the toughest ones to deal with and it is really hard to do this and
be honest. However, if you can find another word that doesn't trigger the corporate
gag reflex, use it.
Dan Rawsthorne conveyed how he did a lot of "mentoring" because "pair
programming" was not acceptable in the "high ceremony, DOD" project he was
on… Mentoring good. Pair Programming bad.
You'll have to be a little more creative to explain who is mentoring whom at
times, but try it.
The CostOfTeaInChinaDoubles Exception
Get over it. Play to win!
No comments:
Post a Comment
Your comments are welcome!