Saturday, October 10, 2015

TDD: First Time Crash and Burn

This is the fourth in a series of posts about Test-Driven Development (TDD). Previously, I posted these:

Eliminating the Self-Centered Ego 

One of the things that makes Aikido different from many other popular martial arts is that there are no competitions in Aikido, unlike say, in Tae Kwon Do or Karate or Wu Shu.

The following are excerpts from the book "Advanced Aikido" by Phong Thong Dang and Lynn Seiser:

O'Sensei Morihei Ueshiba... discouraged competition. He felt that competition... diminished Aikido's application as a legitimately applied martial art. He also believed that competition and the striving for championship status would only further encourage, develop, and inflate the self-centered ego. The learned identity ego, in Eastern thought, is one of the major barriers to sprituality... He felt... that competition would create ego blocks to spirituality.
"Aikido is for the development of the entire human being," states Doshu Moriteru Ueshiba... The mental discipline of Aikido is to overcome our own ego for spiritual development, as opposed to employing Aikido in the service of the learned ego identity, to overcome someone else, thus strengthening what Aikido is trying to minimize.

No Contest

You may be wondering what any of this has to do with TDD. Well, in my previous post, I posited that people who have never written a program with TDD would not be able to write a simple calculator program with TDD. I put out the challenge and gave some requirements for how the calculator should work.

And then came the beat down: "You can't do it! You might think you can, but you can't!"

This is what Destin, the engineer who learned how to ride the backwards bicycle, told viewers of his short and hugely popular video on YouTube. He even offers to pay $200 to anyone who can ride the bicycle for ten feet. I don't think anyone has cashed in on that offer yet. Quite frankly, I think it's a sucker bet and Destin knows it.

I'm not going to put any money on the table for this but I'm betting that at the very least, half the people who take up the challenge of writing a program through TDD for the first time will falter after a few minutes and quickly fall back to their old ways of writing programs, much like those who take up Destin's challenge on the backwards bicycle.

The Agony of Defeat 

As Destin said: You wouldn't think it, but the algorithm for riding a bicycle is just that complicated and any change to one thing throws the whole control system off balance. The algorithm for writing a simple program is pretty complicated, too, maybe even more complicated than that for riding a bike.

"But what does that stuff about Aikido have to do with any of this?" you might ask again.

It all goes back to what I said before about being afraid to screw up. It's the ego, man. It's about not wanting to look stupid. It's about wanting to be a winner.  It's about proving Destin and me wrong about you not being able to do it.

"Ok, whatever," you might say with a roll of your eyes.

But am I wrong? Were you really able to write a little bit of test code, then some production code, then refactor, then some more test code, yada, yada, yada?  Were you able to get through the whole exercise without, at some point, stopping and racking your brain as to what test you should write next? Did you not, at some point, stop and look at the mess you'd made and say, "What the (bleep)?!!! This is horrible! This is frustrating! How can I possibly not get this right?!"

I know this is starting to sound like a lawyer badgering the witness but admit it, it's not as easy as it seems, is it? Admit that you started all over at least one or two times, maybe even more. C'mon, if I can be man enough to say that it also happened to me, which it did, you can at least admit that it didn't go swimmingly well for you either.

I hate to say "I told you so," but I told you so. The truth hurts, doesn't it?

Keep Calm and TDD On

Ok, so if you can admit to crashing and burning on this first outing with TDD, then there's still a glimmer of hope for you. Here's why: I couldn't do it at first but after a while, I finally could. After about two years actually.

As self-deprecating, down-to-earth, and approachable as Kent Beck and most of his contemporaries in the field can be, we all know that the apparent ease and dexterity with which these tests and code can be wrangled is belied by the fact that they are the gurus, gods, and demigods of TDD. It's easy for them to talk about and demonstrate how powerful and effective TDD is as a technique because they practically and quite literally invented all this stuff.

It's kind of like how my fellow students of Aikido around the world and I will watch videos on the Internet (isn't technology wonderful?) of all the Aikido masters and even of the founder himself from way back in the 1960s, and wonder in awe at how easy and effortless they make all these techniques appear to be. And then we try to do them and find out that it's not easy at all.

I, on the other hand, hold about as much candle to any of those guys as a baby to her octogenarian grandmother. I'm one of you, just another Joe Schmoe programmer trying to learn how to get a little better at this job. If I can pick myself up, dust myself off, and power through the pain and frustration of failing at TDD, I think most of you can, too.

So relax, take a deep breath, and try it again. It gets better, I promise. You just gotta keep keepin' on.

Eliminating Competition

So now we know that most of us go into TDD with a good measure of knowledge about it but with little to no understanding that we have what Destin calls "a very rigid way of thinking" which we cannot easily change even if we wanted to.

Were you not at some level fighting with this new paradigm? Were you not struggling against the urge to just write production code first, even for just a little bit? Once you entered that ring with TDD, you quickly realize that despite having all the weapons you thought you needed, you were still ill-prepared for this battle with your mind.

Did you really think it would be that easy to find the magical switch that controls the flow of your thought processes, creating big up front designs and writing production code before the tests? The bias from your past experiences guards that switch very jealously, trying to keep you from flipping it. And when, on occasion, you are able to flip it and alter the flow of your thought processes, your bias continues to fight to flip it back to its "normal" position.

Even if you don't buy all that or want to dismiss it as just more hokey martial arts, Eastern philosophy baloney, that's fine. All I'm saying is that this is how I retrospected about the start of my journey in learning TDD. Retrospecting about it helped me re-align my outlook and attitude towards TDD so that I could be more open minded and accepting of what was happening and what TDD wanted me to do.

Call it mind games, or neurolinguistic programming, or whatever. The biggest obstacle to you being able to go with the flow of TDD is your own bias from past experience and you need to eliminate at least some of that bias to keep going, to get unstuck. That's the competition you have to deal with.

Where's the Code, Dude?

All right, I promised I'd give some demonstrations on how I do TDD and all I've given so far are a bunch of philosophical essays. I get it. You're a developer and you want to see some code.

In the next post, I promise I'll finally get to it. Sorry, but it's the weekend now and the Buckeyes are playing Maryland, with kickoff in less than twelve hours. My daughter is finally going to go for her road test and my wife is bugging me to finish putting up curtains on the new windows and a shower head in our newly-renovated master bathroom.

Next week, I promise, you'll see a lot more code.

Post a Comment