When I hear the word shame, there is only one thing that comes to mind: Slapshot. If you’re Canadian, chances are you already know what I’m talking about. To everyone else, Slapshot is a hockey movie and shame comes from an interview where Jim Carr is talking penalties with Denis Lemieux, goalie for the Charlestown Chiefs. Denis comes up with this to describe high-sticking, slashing, tripping, hooking and spearing…
“…all bad. you do dat you go to du box… you know. Uh… 2 minutes by yourself and you feel shame… you know. And then you get free.”
The reason I bring this up is because I recently heard the word shame used in a chat with James Grenning at the Agile2014 conference. He told me about shame factors that motivate embedded developers toward test-driven development. One of his shame factors was the length time that passed between writing a piece of code and knowing whether or not it’s correct (i.e. testing it). Most would agree that it’s best to cut that time down to be as short as possible yet many developers settle. They wait hours, days or longer before testing thereby (shamefully) dismissing the importance of immediate feedback and maintaining a high quality code base.
Initially, I felt like shame was a pretty harsh word for what James described. But it didn’t take long for me to relate with my own shame factor. If you’re a verification engineer, you may be able to relate, too.
I run an RTL test, I believe I’ve found a bug in the RTL, I take it to the designer and a couple hours later he/she bounces it right back at me.
“You’re right. There is a bug”, they say, “but it’s in your testbench, not in my design”.
That’s it. That’s shame for me. I hate the idea that I can use a bug I’ve created to waste someone else’s time and when it happens I feel like a tool. Indeed, I go to the penalty box (i.e. my cubicle) and feel shame.
Feeling that shame regularly was part of what motivated me to start using TDD. I got tired of wasting other people’s time. I realized that trying harder wasn’t the answer so I tried a new technique entirely.
Thankfully, getting better is exactly what’s happened. Sure, I still create defects and I still feel that shame of wasting other people’s time, but it happens much less often than in the past. Basically, TDD helps me write code I can feel good about while the defects that linger remind me that there’s still room for improvement.
There it is… the shame of creating defects and how TDD can help you “get free”.