Extreme Programming Pocket Guide

Chapter 22. Starting Feedback

As your team continues to improve, start gathering feedback. This will allow you to see change occurring and to adapt to it. If you’re fortunate enough to have a customer right now, great! Getting her feedback will help guide your development. If not, you can still learn from the feedback loops within the coding process.

The most important question right now is “Does the code work?” The only way to know is to test it (see Developer Practice 1: Adopt Test-Driven Development in Part II). Test-driven development will give you immediate confidence that the current code acts as it should and long-term assurance that new bugs and regressions can be fixed quickly. You must trust each other to write new tests, to run existing tests, and to fix broken tests.

It’s much easier to start testing from the beginning, but few projects have that luxury. Halting new development to add tests retroactively is unpleasant and time consuming. Instead, adopt test-driven development for all new features, including bugfixes.

Writing a test for a bug before you fix it has several benefits. First, it defers the cost of retroactive testing until it’s needed. Noticing the bug tells you the code is wrong. Capture that knowledge in a test! Second, it adds tests where they’re most needed. Third, it prevents the bug from reoccurring. (Too often bugs are fixed and subsequently unfixed several times.) The buggiest—likely ugliest—sections of your code will benefit from ever-improving test ...