I’ve always felt sort of ambivalent about “test-first approaches” to building software, a big thrust in the Agile programming movement. My general feeling was that it seemed superficially like a good thing to ask for, but because I faintly envisioned some flaws in the approach, I bit my lip and kept silent on the matter. But recently, a fan of my book,Facts and Fallacies of Software Engineering, who liked what he saw there and was contemplating using it as the basis for the team of software folk he had recently been put in charge of, wrote to me to ask how I felt about that “test-driven” idea. And for the first time, I forced myself to come to grips in depth with what I thought. Here’s what I said to him. Some of it surprised me as I opened my electronic “mouth” and listened to what flowed out of me! Regarding “test-first” approaches, I am slightly negative on them. The fundamental idea is good. But one of the things I’ve always been concerned about with testing is the possibility that the software is written to make the test cases succeed, rather than to achieve its required functionality, do its job. That is, the software is “trained” to pass the test cases more than to meet its requirements. And, of course, if that happens, then the test cases are a negative influence, because lots of faults of various kinds, especially those regarding meeting requirements, may slip through the resulting testing sieve.