Test before check-in model would certainly be a big improvement over debug later programming. I suspect that the longer feedback loops would impact the time to find the bug, but I would expect that code written and tested in the same day would be significant improvement over the debug later approach. I agree with you assessment of TDD advantages. I might add the TBCI might suffer from some testability issues as a result of test being a second separate task. I expect that some individuals would get very good at this.

James

I bring this third alternative up because the challenge with getting TDD adopted is in my experience not only to argue for it in relation to debug-later programming but also against those that in fact are quite good at writing unit tests for their code although they don’t do it TDD style.

If you can consider that alternative in you models somehow that would be interesting. The challenge with doing this however is that the arguments are not that easy to put a value on as you do in the existing model.
Some advantages I see with TDD in relation to test before check-in:
*Lower coverage becuase you tend to writ less unit tests when you write them after the code (so you still get some “debug later” effects)
*Feedback loops are slightly longer (from a few minutes to a few hours, what is the additional cost of that?)
*You loose the too me important effect of written tests that first are expected to fail but due to an error in the test don’t (not noticed with test last unit tests).
*Impact on design (not so simple and “testable”)

this is a common sense and logic chain argument. I’ll look for data to back this up.

James