I just wrote a page on our internal wiki with our policy for dealing with build failures. We thought others might find it interesting so I am sharing it here (the links will be broken for obvious reasons).

Executive Summary

If the build fails, fix it.

Scott Ambler calls it Green Shift, but it sounds more like Bull Shift to me. (via Jason Yip)

Nine gathered tonight at the Thoughtworks San Francisco office tonight, 4 of whom attended Agile 2006 and 5 of us did not. Things I remember from the conversation, in no order of importance:

• Agile has crossed the chasm, "everyone doing it" was the word on the street
• Success stories even in very large teams/companies
• Wanted more discussion on how to change culture
• Coding Dojo session was excellent and would make for a good future BayXP meeting
• Data no longer a four letter word! (Refactoring Databases)
• Surprisingly valuable discussion by some Microsofties of their TDD Pair Programming Game (complete with phase transition diagram)
• The Open Spaces part was allocated a horrible space -- think low ceilings and harsh lighting -- and this combined w/the relative neglect compared to previous years led to a feeling of low energy...
• ...except the Getting Things Done session got high marks
• Crushing Fear Under the Iron Heel of Action got high marks with Ron and Chet described as living cartoons (in a good way)

I know there was more but I didn't take notes, so that's all you get, unless some kind soul adds more info in the comments.

In early August J.B. Rainsberger gave a webinar on TDD for J2EE:

Test-Driven Development is often introduced through simple examples, but many developers would rather dive into the deep end. This free webinar is for those people. J. B. Rainsberger, author of "JUnit Recipes," will show you architecture and design strategies to make it easier to "test-drive" J2EE components. You'll learn how to build a J2EE application while following the cardinal rule of Test-Driven Development: Never write a line of production code unless somewhere, a test has failed.

The recorded webinar is up on the Agitar website linked from this page. Registration is required but if you'd rather not register try out bugmenot.com.

Greetings,

We are proud to announce that registration is now open for the next Continuous Integration and Testing Conference, CITCON London 2006 on October 6 & 7. Space is limited to the first 120 registrants and attendance is free. Registration is on-line.

The conference will be following the same Open Spaces (or unconference) format as the very successful Chicago edition back in April 2006. The Chicago CITCON drew an enthusiastic group of practitioners, all looking to share what they knew and to learn what they could.

We would appreciate your help in getting the word out. Please blog/post/email/chat about CITCON London 2006!

We hope to see as many of you there as can make it.

Sincerely,

Paul Julius
Jeffrey Fredrick
Chair-people, CITCON London 2006

There are many reasons why you might not want to fix a failing test right away. Maybe it's an acceptance test for a feature that you haven't written yet. Maybe it's a regression that it's just not practical to fix right now.

But what to do with that failing test?

If a little bit of feedback is good, a lot would be even better, right?

Is there such a thing as too much feedback?

XP doctrine says that you should stop tracking metrics once they have served their purpose. You should only have 3 or four "Things To Focus On". There's a reason for that.