The Larger Significance of the Royal TDD Rumble
Let’s Get Ready to Rumble
Tomorrow (this) morning at 11 AM Eastern time, the world is going to tune in on Pay Per View to the greatest rumble this side of the Thrilla in Manilla that pitted Muhummed Ali against Joe Frazier. Nearly 40 years after the original, the 2014 incarnation will pit the creator of Ruby on Rails against the creator of Extreme Programming and the TDD approach as well as an internationally acclaimed author and speaker in and about the field of software engineering. The venue will be google hangouts. Get your tickets before the internet sells out.
The reason for the brouhaha? A post entitled, “TDD is dead. Long live testing.” From there, a long series of subsequent posts, debates, arguments, etc ensued across the development world. So, after a couple of weeks of this, the battle was set between the TDD antagonist and a couple of proponents. Or something like this. (Might be that this isn’t a death match, since Martin Fowler explained, “We hope to be witty and entertaining, but we are more interested in exploring these topics in a way that expands our understanding of each others’ ideas,” but what’s the fun in that?)
Of late and I guess in general, I’ve written a lot of posts about unit testing, automated verification and test driven development, so suffice it to say that I’m a fan of this practice. So, one might think that I’d watch this hangout rooting for Fowler and Beck to win, the way I root for the Chicago Bears on fall Sundays. But to be honest, it doesn’t really bother me that someone, even a well-respected and widely known industry figure, doesn’t do things the way I do them. I don’t need or even want everyone to agree with me if for no other reason than this state of affairs would present me with new ideas to consider. If DHH doesn’t find TDD to be beneficial, I’m sort of curious as to why, and I might disagree, but it’s no skin off my nose.
Might Doesn’t Make Right
The tone of this post started off breezy and satirical, but I’d like to get a little more serious because I think there’s a lot of effort, money and happiness at stake. There are two competing attitudes at play in the hubbub surrounding this conversation and pretty much any tendency toward disagreement: “my way worked for me” and “my way is the right way.” I try hard — so very hard — to be someone who says or means the first thing. It is my sincere hope that this attitude permeates any blog posts I make, content I publish, and talks that I give — that they all have an implied “this is based on my experience, YMMV.” I might not always succeed, but that’s my goal. I take this with me at work as well; even with people that report to me when I’m reviewing code I don’t tell them what to do, but instead offer what I would do in their situations. I think this is critical with knowledge workers. It becomes a matter of persuading rather than forcing, which, in turn, becomes a matter of needing to earn respect rather than “might makes right.”
The reason, I think, that the Expert Beginner series resonated with so many people is because the Expert Beginner is “might makes right” incarnate, and it’s something that has invariably squashed your motivation and made you hate your life at some point during your career. Expert Beginners say “my way is the right way” and even “my way is the only way.” This is a characteristic of micromanagement and lack of vision that reduces knowledge workers to brainless cogs, and therein lies the effort, money, and happiness to which I referred.
I’ve left projects or even jobs to avoid “might makes right” Expert Beginnerism, and no doubt so have you. This is lost opportunity and value. Poof. Gone. 2 weeks notice, “knowledge transfer,” on-boarding, and starting all over. Running in place for organizations and projects.
Now, all Expert Beginners tend to think, “my way is the right way,” but not all people who think this way are Expert Beginners. In fact, some are legitimate experts whose way probably is a great way, and maybe even “the right way.” It’s human nature, I believe, to think this way. People form opinions and they want others to agree with those opinions. If we decide that a gluten free diet is really the way toward better health, not only do we expect others to be interested in our newfound wisdom and to agree with it, but we’re even offended when people don’t. I’ve been bored to tears watching this phenomenon take place over and over again in my Facebook feed.
As humans, we seem naturally to want our advice to be heeded, our opinions validated and our approaches mimicked. In my travels, I started doing TDD, and I found that it helped me tremendously and made me more productive — so much so that I post about it, create courses on it, and teach it to developers on my teams. So, if someone comments on a post about it saying, “that’s just a bunch of hippie crap,” my natural inclination is to be offended and to feel combative in response (and indeed, phrased that way, confrontation would appear to be the goal of such a comment, no doubt coming from someone who felt that my posts were an affront to the approaches he’d found to be helpful).
But I try to fight this as much as I can, and listen more to other people and see if I can understand why they do what they do. The irony is, this approach, counter to human nature, is actually in my best interests. I learn far more by listening to what others do than evangelizing for what I do. It’s hard to go this route, but likely beneficial.
Now, I’m not attempting a relativistic argument here to say that if someone’s experience is that they’ve “enjoyed success” by shipping non-compiling code that’s just as valid as someone who delivers reliable software. It’s not that everything is just a matter of feelings and opinions. Approaches and outcomes can and should be empirically measured and validated so that objective, collective progress can be made. Approach X may indeed by better than approach Y, measured by some metric, but those in camp X should be persuading and demonstrating, rather than shouting and flaming.
I doubt the software industry is unique, but it’s the one with which I’m familiar. And it’s frankly exhausting at times to see how much time people spend getting worked up and defensive because someone doesn’t share their love of some framework, approach, or technology. It becomes heated; it becomes personal. You’re an unprofessional hack because you use programming language X. You’re a sellout because you buy tools from company Y. My goodness people, settle down. Honest debates and exchanges accomplish a lot more for everyone. The esteemed gentlemen having the hangout tomorrow to discuss the merits of TDD seem to be favoring the “cooler heads” approach and it’d be nice for everyone to follow suit.
I think test driven development is the best approach to writing software to which I’ve been exposed (of course, or else I wouldn’t do it). I think that if you have an open mind and are willing to try it, I can persuade you that this is the case. But maybe I can’t. And maybe, there’s some as-yet undiscovered approach that someone will show me and I’ll be sold on that instead. Whatever the case may be, I’d like to see these types of exchanges favor attempts at persuasion as opposed to shouting, heated personal exchanges, or, worst of all, “might makes right” types of fiats. And, I think at the end of the day, we all need to come to grips with the knowledge that not everyone out there is going to share our opinions on the best way to accomplish a task. And hey, if your way is really better, it sure looks like you have a competitive advantage now, doesn’t it?