Visit Agile Thoughts and register to receive free development, analysis, or leadership and management materials and learn to excel at developing software. I’ll also send information on my low cost email courses you can take via the internet.

(A Code-Dog is typing away, the Agile Thoughts podcast playing in the background. Vanilla Pop enters the room.)

 

Code-Dog: Well good morning to you Pop. You got in early. It’s only 10am.

VPop: yeah yeah. I’ve been listening to this podcast and wanted to try some of the ideas out.

Code-Dog: Whoa! Whatcha cooking up? A test class?

VPop: yeah! I’m building some micro tests as I build the code and–

Code-Dog: You what? Did you say write tests *as* you build the code? You mean after you build the code, and only if you’ve got some time left before the Sprint ends.

VPop: No, I mean I’m writing the test before that. It’s called TDD and–

Code-Dog: Dude I’ve hear of Test Driven Development and that’s some messed up shit!

VPop: Well I got this book called TDD by Example, and I’m giving it a go.

Code-Dog: You remember Instant Nugget? Over in accounting? His boss told the whole team they had to start doing it. And none of them knew how…. so they wrote the tests later and I guess they didn’t make enough because they still haven’t deployed their app.

VPop: Yeah. That project is a steaming pile of bugs. So yeah. I’m giving it a try in case our manager makes us do it.

Code-Dog: Nuh uh, there is no way. All the other managers in the company are too scared after that.

VPop: what did they expect when no one on the team knew how?

Code-Dog: So that’s how it is huh? YOU’re learning now so they can make us do it later. Man I don’t know… Maybe better you don’t so we can keep things cushy the way they are…

VPop: You know that last Sprint, I spent most of it tracking down a problem in production? It must have been a code merge that changed that fouled up a Handler class.

Code-Dog: yeah, that sucked. But hey, everyone understands that you needed to solve that.

VPop: But we didn’t need to have that problem. If we did TDD on all new code changes, we’d work on adding new functionality because we’ll not have bugs.

Code-Dog: Come on! No bugs? Have you every seen that happen? Like ever?

VPop: I hear you, but yeah, some of my friends at other companies are shipping features every day… they just don’t ship something that fails an automated test. And if you’ve a lot of tests, then it stands to reason you won’t get bugs slipping in.

Code-Dog: Stands to reason. But writing a lot of automated tests takes a lot of time doesn’t it? I mean how long have you spent the morning on this? I bet you could have finished it by now…

VPop: (sounding embarrassed and a little defensive) yeah well I’m learning how… and hey, losing a person a sprint to fix bugs has already slowed us down. The author and this Agile Thoughts podcast both say that a lot of developers spend 50% or more of their time in the debugger tracking down problems while they write code.

Code-Dog: You betcha! Gotta confirm the computer is running it the right way.

VPop: Exaclty! You’re manually unit testing your code and those confirmations you made will never ever be run again. But–

Code-Dog: Lay it on me Socrates.

VPop: But if we add tests as we write the code, we’d capture developer intent. And those micro tests will be checked in and executed to defend that code from regression forever.

Code-Dog: Hmmm. Hold on there Brave New World. Bonus time is approaching. Are you going to risk your bonus on this TDD? Come on, isn’t TDD taking you longer to finish the story?

VPop: Well…. yeah I do feel slower. And it’s making me think a lot harder.

Code-Dog: Well if you figure it out, you can teach me. As for me, I’ve got to get to work.

 

Narrator: an early adopter, Vanilla Pop, has discovered TDD and is attempting to apply it. Code-Dog has only been a source of fear, uncertainty, and dismay. This common developer habit, fear of committing to an uncertain path, comes from conditioning of being held to commitments and sometimes failing. As a result, when faced with innovation, a team may push its members to avoid innovation and stay the course. As a team member or manager, your job is to encourage movement in the right direction. As a manager, you need to be cautious and not be like the mentioned manager, who command and controlled his team into a ditch because they really weren’t capable of success.

 

A good strategy is to elevate those with new ideas and give them room to experiment in the face of FUD: Fear Uncertainty and Dismay. Measure their experiment for success and then, if the strategy shows signs of success, have the innovator pair program with the others until the whole team has the new capability.

 

Next episode we’ll see how Vanilla Pop performs after this injection of FUD.