Possible causal point for a failure to value TDD: geeks thinking the main source of bugs in professional software is not handling the main case successfully.
In any feature in any app, there are one or more primary cases. A given story is likely to be concerned with one of these at a time. When you’re geek-young, the great challenge is just to close out the primary case. Hell, you barely learned the syntax, you’re just learning the library-set. Just getting that primary case running is a big deal.
It takes a while, but with some practice, these primary case problems get easier and easier. You learn the syntax for real. You’ve used enough of the library to suspect or increasingly know how it was intended to be used. You are getting stronger, and that’s great. You find yourself making solutions in your head before you’ve even heard all the problem. And altho that has its own risks, you generally are making headway all the time.
When you go pro, tho, three factors emerge, all of them based on size.
Because your app is larger, there are more people changing it, more cases to grasp, more things to remember.
- More people means more worldviews. Assumptions you’ve made in your code are quite likely not the assumptions made in theirs.
- More cases to grasp means more possible code-paths. Assumptions you’ve made about when and where and why your functionality is being called are far more difficult to make.
- More things to remember means slower and slower thinking. Human brains are optimized for a very narrow bandwidth. No matter how much you resemble an encyclopedia, sooner or later you become nearly paralyzed.
And somewhere in this not-quite-so-geek-young phase, you will hopefully begin noticing that standing up the isolated main case really just isn’t that hard, comparatively. You bone up on design, which isn’t mostly about solving isolated main cases anymore. It’s about a new level of the game. (like when you finally realize potting simple pool shots isn’t the hard part of pool, or that bouncing between knit and purl isn’t the hard part of knitting. There are lots and lots of games-for-a-lifetime, and geekery is one.)
After a while spent learning the patterns and their beautiful variations, experiencing the joy and despair of walking around chanting "it’s really just an X. everything is just an X. It’s X’s all the way down!" you reach yet another game. You begin to understand how much time and energy you are spending on problems caused by assumption mismatch and tacit knowledge and trivial one-liner flaws.
TDD — really a shorthand for me for "the modern synthesis of software development" — offers a variety of ways to mitigate or even eliminate that pain. And as you adopt it, your successes increase, and your failures decline. And blammo, you’re a pro. This isn’t a switch, it’s a process, and it takes time. Fortunately, you have time, cuz it pays back almost immediately.
And now you’re in a place where you can look back on those other periods and ask, would TDD have helped me even then?
My answer: yes, oh hell yeah. Because those assumption mismatches, tacit knowledge failures, and one-liner flaws, THEY WERE COSTING ME THE WHOLE TIME. I just couldn’t see it. "just make the isolated main case actually run, please lord please," was all I could attend to. Tho I felt like the isolated main cases were the hard part, I was wrong. The hard part was still what it is now: assumption mismatch, tacit knwoedge failure, one-liner flaws.
I’m old enough to have climbed many mount stupids, and the odds are good that i’m climbing one just now. But at my current stage in the game-for-a-lifetime called geekery, I believe that TDD would have walked me through all the earlier stages far faster.
TDD is so powerful because it lets you kill off so many distractions from "just get the next main case working."