Let me explain the team “never touched the initial code”. The project was getting moved left and right because of QoR issues, but without real improvement. That was happening in the middle of drastic changes (major outsourcing…), so I ended up working with a small team of people in Bangalore to take over that project. In that team, only one person was somewhat familiar with the code, and nobody had any training in terms of software quality. TDD was the perfect opportunity *and* the only option to use there, because (1) as you pointed out, there was no objection to go that route since the developers had not seen any route so far, and (2) because we couldn’t have relevant training sessions on the code, so it was better to have people jump in and fix issues as they were refining the unit tests, which led them to re-learn and re-appropriate the code.

One question: I don’t quite get the point you were trying to express in emphasizing that the team “never touched the initial code.” I can read it two different ways with nearly opposite meanings: “TDD is so powerful that it drives improvement even with developers who don’t understand the original code” or “TDD works best with developers who have not been prejudiced by the original code.” (And neither may be what you intended!) Can you clarify?

Yes, TDD works pretty nicely, as long as you have a team or a leader dedicated to it. How many people in your company? Any other specific benefit of TDD you can share with us?

Although you alluded to it, ease of maintenance is another huge advantage.