A fast-moving R&D system is the easiest and most fun kind of programming. Type systems, unit tests, and elaborate test frameworks are all too heavy to keep up with R&D programmers as they strive to find meaning in data, a new solution to a hard problem, or the Nth magic iteration of the software that will prove that a startup has value.
On the other side, as in the attached quote, we have NASA. Billions of dollars in equipment and labor poured into a project and only one chance to get it right. In their case redundancy, tests, and correctness are everything.
So the debate about whether types, tests, and test-driven-development have merit comes down to the answers:
"No," I want to move too fast to support the redundancy introduced by those mechanisms.
"Yes," I need correctness more than anything to protect my billions of dollars invested.
"It depends," how much each tool costs to use. How much extra work will it be to bend the type-system and update the tests any time a change occurs? Language designers are forever trying to provide the value of type systems and verification without a tax on the programmer. However, in the final analysis, all advanced correctness features add conceptual complexity to the process.
My personal tradeoff is to look at projects in a maturity model. In the beginning you may not know what you're doing or what you'll deliver. Then I would use no unit tests, a language with no type system, and only the minimal amount of verification for tricky algorithms. Sometimes the problem is perfectly well understood at the beginning, or, your R&D phase ended in success. Now you are done with exploratory programming. In this stage, start with a language with a good type-system and invest in the effort to create a mature test harness for the system. If you ever get to the NASA stage, good luck. It takes a lot of time and money to invest in the rigorous duplication of effort described in the article (and a special kind of mania). I would certainly retire any existing R&D code and start from scratch if you're going to the moon.
As a practical matter, most of my projects have matured after an initial R&D period. I start out with very little testing and then, as things become more certain, I begin to write unit tests for every new change in the code by first verifying the old behavior with a test that confirms all of my assumptions. Then when I write a new test and the new code for the change.
