|laziness, impatience, and hubris|
It was, to “lil” ol” me,” absolutely staggering what a (positive) difference it made.
It really felt to me like I had just wandered into the hunting-fields for the very first time with a really good hunting dog. :-D
“Wow! How'd all those pheasants get in here?!”
The rigorous, early testing-process flushed out an unbelievable number of errors. But it also made the resulting code much more reliable.
When we're in school, we're taught a lot about data structures, but we're really not taught about ... code structures! Animators and engineers know about the concept of “degrees of freedom,” but we neglect to teach software engineers that exactly the same concept applies to their work ... only “eversomuch more-so.”
Any “unanticipated movement,” lurking anywhere in the moving-parts-laden structures that we universally build, has the potential to de-stabilize the whole thing, and to express its movement in any number of well-concealed indirect ways. Only by systematically ferreting out these “movements” early, under (admittedly artificial) conditions designed to minimize the number of moving-parts that might have been layered on top of them, can we ever hope to say ... with any degree of assurance ... that “even though I do not yet know what is causing this problem, I can say that it probably isn't this-or-that.” Otherwise we spend too much time trying to deduce where the problem(s) actually lie.
Fixing them, once we find them, is usually trivial. But by then, the economic damage has already been done.