Wow! Great post and a great thread from everyone! I have been in a bit of a challenge lately at work trying to help our leadership find better...but minimally intrusive...strategies for producing better systems (especially flight software systems).

We always produce a large, strategic suite of tests (we call them, somewhat conventionally, Baseline Functional Tests (BFTs)) that are developed once the code and hardware are produced and have been through module- or subsystem-level testing. In short, our tests always "follow" after our development.

The price seems to consistently be twofold: (1) we seem to find it hit-n-miss finding "big" errors and (2) we have to go back and make significant changes to our tests after we fix the errors.

This results in quite a bit or wasted time (in my opinion) and leaves our leadership wondering "did we find enough of the big errors?"

I have read a number of posts over the past couple of years here and had been somewhat swirling around the notion tha perhaps a more test-driven development approach would help. The comment that ...Initial code-writing took about twice as long as before. Overall development time was far less is actually at the heart of almost every discussion I've had around here on the matter: the fear that things will take so much longer. But your sub-comment on overall development time is at the heart of what I've been thinkking and your articulation of that point strengthens my resolve.

This post and subsequent thread has renewed my thinking and strengthened my resolve to move more aggressively in this direction to see what it brings.

Thanks to everyone for the great dialog; it really helps...as the Monks always do.