I'm not sure I understand exactly how this is different from the way I've always designed software. I pretty much HAVE to have a test harness in order to develop engine functionality. The harness is usually designed to bang it about quite a bit more than in normal deployment.

All the Best Programmers, Self Medicate/Meditate and know XXXXactly where they are Going and where the Code can take you. IT is the very Essence of Being for All of the Best Programmers/Code Phreak Units.

That way is the Code written FailSafe and HindSight Secured in ITs ForeSight/HyperVision.

It's not new, but it's not observed/used as widely as it should be -- something it has in common with most good practice in the software industry.

Designing for testing helps to make people consider dependencies, which tends to make for better, more maintainable software in itself. XP mandates design for testing (and doesn't do Big Design Up Front) as interfaces are designed as part of writing tests.

For if you design your code like this you should be condemned to a life of conference calls, and serial status meetings.

I'm sure the author is progressing apace on the glittering crystal ladder at Accenture - or is it Atos?

Just because you can write some crappy UML for some crappy EJB doesn't mean you should... CalculatorBean? CalculatorProcessor?, CalculatorProcessorFactory? afterPropertiesSet? Here be madness.