XP Is Weird

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.