Test Early

The earlier a problem is found, the easier and cheaper it is to fix it.

Therefore:

TestEarly: minimize the amount of time between the creation of an artifact (specification, code, user documentation) and it's verification.

Applications:

Many methodologies call for code reviews as soon as the software compiles cleanly and has passed some minimal sanity tests. (Other artifacts get comparable reviews, also early.) Code reviews are said to be very effective (as measured in staff hours per defect) in finding bugs; so put them early in the process, so less time is wasted dealing with them later on.

ExtremeProgramming calls for UnitTests to be written before the code. (Gold star for reducing the time to zero; no extra credit for reducing it below zero.)

www.washingtonmonthly.com/features/2001/0112.umansky.html : The U.S. Navy insists and more and earlier "operational tests" (and more realistic ones) than the other American armed forces. Result: Navy systems are fielded sooner, and are more likely be combat ready when fielded, than Army or Air Force systems. Example: the B2 bomber and Predator drone can't fly in the rain, and that was discovered too late to do anything about it.

The trick is not merely knowing to TestEarly, but knowing to push back when told "it can't be done." --PaulChisholm

you should also ReleaseEarly if possible.