Symphonious

Doug suggests that XP isn't a solution to your problems. Mostly I agree, however XP does make you feel bad - and in this case, feeling bad is good. As Doug points out, XP brings things out into the open which makes people feel bad about them. The lack of tests for your product - oh, that's not good. Not doing continuous integration - tut tut tut. Your build is regularly broken? Shame on you! Feeling bad about these things is good and will encourage you to fix them.

Too many teams consider broken builds "the way things are done", we don't do test driven development so we don't have good test coverage, that's just the way things are done here. XP comes along and points out the costs of the way things are done and provides a pathway to make them better (albeit a long, winding one a lot of the time and with no street lights for the first half of the journey). With a good team of people, XP will take you to a better place even if the current situation is bad.

The flip side of that of course is that XP also highlights the good things. Test coverage improving - yay, that's great! Delivering value to your customers faster - big win! There is a lot of positive feedback as you improve all the way from little wins when you find a simple design via TDD to big ones where you make your customers really happy. The feeling of the "XP way" and "getting XP" encourages the good and discourages the bad.

That said, if you're on a bad team I think XP would make things much worse - it requires a lot of dedication and commitment, it takes trust in the team to make it work. XP is about turning all the knobs to 11 but with a bad team, particularly an uncommitted team, you may find the knobs only go to 8 and that's only going to lead to problems.

There's a big difference between code you write when you're fresh and code you write when you've just had enough. I obviously had a relaxing weekend, because today my approach to coding was surprisingly well behaved - even when I had to modify legacy code that had no test coverage I made sure I wrote new tests before I touched it. Getting into TDD for new code is one thing, building up the discipline to add tests to existing code before making even a simple change is really tough.

Fortunately, if you know you're getting lazy you can manage it either by paying more attention to the process and taking smaller steps or by doing something simpler that requires less concentration. The real danger is when you aren't aware that you're fading out and taking shortcuts - that's where you really need a pair to step in and pull you up.

As you spend more and more time developing good unit tests as part of TDD, you regularly find yourself writing the same thing time and time again. Fortunately, TDD also includes a refactor step to remove this duplication again. I've found it quite interesting that over a few weeks of this, we've actually developed a complete language for asserting the correct output. For example:

assertStartTagSpec(HTML.Tag.HTML);
assertStartTagSpec(HTML.Tag.BODY);
assertStartTagSpec(HTML.Tag.P);
assertContent("Hello World!");
assertLineEnding();
assertEndTagSpec();
assertEndTagSpec();
assertEndTagSpec();
assertEndOfSpecs();

Even without the domain knowledge, it should be fairly obvious what is expected. It's definitely a lot clearer than:

ElementSpec spec = specs[0];
assertEquals(ElementSpec.StartTagType, spec.getType());
assertEquals(ElementSpec.OriginateDirection, spec.getDirection());
assertEquals(HTML.Tag.HTML, spec.getAttributes().getAttribute(AttributeSet.NameAttribute));
spec = specs[1];
...

Notice how even the specs array and the current offset within it is hidden. The human brain naturally identifies the code as a progression and so the extra clutter just gets in the way. Over time we've added all the different variants of these methods that we need by overloading the methods so that we can specify additional attributes etc, without needing to specify the default values all the time. The end result is that we can see the important parts more clearly and get to that green bar faster.

Chuq Von Rospach has some interesting thoughts on tagging - must come back to this and have more of a think about it.

It seems I finally pestered Doug into blogging again, so for his side of the story check out Experiments in Software Design.