They’re called Practices for a reason

People ask whether they have to do the XP practices to be doing XP. In some environments, some of the practices are difficult or impossible. You don’t have to do the practices to be doing XP: You have to have done them. Practice makes perfect.

Kent Beck has begun referring to the XP practices as “etudes”. In music, an etude is a piece that you play, not so much for its beauty as for the technique it teaches you. Etudes are generally for practice. But an etude can also be a piece featuring technique, but played as well for its artistic merit. In what sense are the XP practices just for practice, and in what sense are they for real? Let’s look at some favorites and explore.

Test First Design

A technique that is fairly unique to XP is Test First Design. This is a practice where you program by writing a little test, then a little code to make the test run, then a little more test, a little more code, and so on. Test first can be incredibly powerful in the hands of a practiced player. Some of the benefits include:

  • The practice provides essentially 100 percent test coverage for code written test-first. While testing experts will tell you that coverage isn’t everything, many organizations find that they have far less than 100 percent of their code covered by tests.
  • Often programming feels like building a house of cards in your mind: if you get interrupted, it all falls down. Test First isn’t like that. You go in tiny steps, and if interrupted, it’s easy to return to the task later.
  • The designs we come up with with Test First seem to be simple and elegant. They are often different from what we imagined we’d do — and better.

Etude, or Concert Piece?

You decide. I suggest that you need to practice Test First Design until you are really good at it. Even when you’re beginning with the technique, it’s a decent way to proceed. Try it on different kinds of tasks: ones where you know exactly what you want to do, ones where you haven’t a clue. Try it with different partners. For spike solutions or work at home, try it on your own.

I think you’ll find TFD to be a useful technique. Whether you’ll use it all the time — some of us do — or just on special occasions, you’ll make the right decision for yourself.

Unit Tests

The Unit Test practice in XP predates Test First Design, and is more broad. Put simply, XP suggests that programmers need to test everything “that could possibly break”. Now if you are inclined to take things literally, this could lead you to worry about testing your program to make sure it works when the computer is struck by a meteor or the source code is changed by aliens from another universe. That’s not what we have in mind.

What we have in mind is that you will use your judgment, but that you will work hard to think of things that could go wrong, and whether you should test them. Often, as programmers, we are full of ideas for the next solution, and tend to skip over testing that could pay off. Test First Design helps us avoid this problem, but even if we don’t do TFD, we still need to make sure we’ve done enough.

The rule “Test everything that could possibly break” cannot be satisfied. That’s why we put it that way: to keep the pressure on. Why do we care so much?

  • Debugging is often difficult, time-consuming, and hard to predict. When an unexpected defect shows up, it disrupts planned work, drives everyone crazy, slows down progress. The best way to avoid these problems is to have very few defects. One good way to have few defects is to have good, comprehensive tests.
  • XP is an incremental development process. We know we are going to change the design; we know we are going to change the code. And, as experienced programmers, we know that when we change things, no matter how careful we are, some odd thing over in the corner always seems to break. Comprehensive unit tests are protection against this oversights: the more tests we have, the more likely our little mistakes will be found right away.
  • Another whack at the same horse: XP develops incrementally through refactoring. Refactoring means improving the code design incrementally, without changing function: in particular, without breaking anything. More tests, more certainty that we haven’t busted it.

Etude, or Concert Piece?

Concert Piece. Learn the techniques of unit testing, but then continue to use them. We trust you to find the balance between “everything” and what you really need to test. And we’re sure that you really do need to test.

Conclusions

In one sense, there aren’t any. The XP practices are the beginning, not the end. One of my irritating email signatures says “The practices are not the knowing. They are a path to the knowing.” This pompous pseudo-Zen saying holds an important truth:

When we do the XP practices until we are good at them, we learn some important things: we learn new ways to design, new ways to find errors. We are learning new techniques that go into our bag of tricks, to be used as we need them in the future.

Real XP is not the techniques, not the practices. Real XP is the development of software by programmers who are expert in their techniques, keep them honed, and use them with judgment in the light of experience.

How do you get to XP? Practice, man, practice.

Posted on:

Written by: Ron Jeffries

Categorization: Articles

Recent Articles

Refactoring — Not on the backlog!

There has recently been a lot of noise on the lists, and questions at conferences, about putting refactoring “stories” on the backlog. This is invariably an inferior idea. Here’s why:


Ref01

When our project begins, the code is clean. The field …

Build it right to build the right thing

You can’t build the right product if you can’t build the product right.

I tweeted that this morning, in response to a Twitter-vibe that was flitting around. I’d like to follow it up here with a bit more meat.

The …

Issues with SAFe

Recent Twitter conversations inspire me to pull out some of my concerns with SAFe and talk about them.