Maybe it's the Object Thinking talking but I always balk when I hear someone talking about taking an agile practice and making it into a "rigorous engineering process." Check out this bit from The Code Project: Unit Test Patterns

However, to achieve this acceptance, unit testing must be formalized so that it becomes a real engineering discipline rather than an ad hoc approach that relies on the dubious capabilities of the programmer.  After all, the unit test is supposed to test the code that the programmer writes.  If the programmer writes bad code to begin with, how can you expect anything of better quality in the tests?  Of even more concern is the concept that the unit test should be written first, before the code that is to be tested.  To a certain extent, this implies that not only does the programmer have to consider what the code will do, he/she has to consider how the code is designed.  Both drive the interface.  This is why many people balk at the idea of writing the unit test first--it places them in the uncomfortable position of having to do up front design work without consciously recognizing that this what they are doing.

"Ad hoc approach that relies on the dubious capabilities of the programmer"? If we don't trust a certain programmer, why are we letting him code on our project? Why aren't we trying to make him better? We're never going to create a process that protects us from all bad programmers.

Counterpoint: You can write FORTRAN in any language.

Great quote right from the begining:

Whatever language you write in, your task as a programmer is to do the best you can with the tools at hand. A good programmer can overcome a poor language or a clumsy operating system, but even a great programming environment will not rescue a bad programmer. —Kernighan and Pike

The systems that are going to suceed are those that give developers freedom to change and to effect the system. Systems that teach a developer make great developers and that's the key to good software: good developers.