Thanks! And I have not seen any teams doing this kind of thing either.<p>Another tidbit: The developer pairs were responsible for writing <i>both</i> the production code and associated automated tests for the production code. We had no &#x27;QA&#x27; &#x2F; test developers. All code would be reviewed by a third developer prior to check-in. However, at one stage we tried developing all the test code in a high level scripting language with the idea that it would be faster to write the tests and need less lines of test source code. However, because we did several projects like this, we noticed that there was no advantage to writing tests in a scripting language. The ratio of production C source lines to test source lines was about the same whether the test source code was written in C or a scripting language. Further, there was an advantage to writing the tests in C because they ran much faster. We had some tens of thousands of tests and all of them could compile and run in under two minutes total, and that includes compiling three version of the sources and running the tests on each one; production, debug, and code coverage builds. Because the entire test cycle was so fast then developers could do &#x27;merciless refactoring&#x27;.