- Consulting / Coaching
- Jeff’s Blog
I delivered a talk on “The Only Agile Tools You’ll Ever Need” at Agile 2011, and had a great time doing so. Most of the written feedback from the session indicated that people were very happy with the talk. Negative feedback, received from a handful or so of the ~60 attendees: It didn’t necessarily meet expectations based on what the session summary said. I apologize for that–I’d prepared the summary months before putting together the talk, and what I’d felt important to say changed during that time.
I also muffed a bit–I made a forward reference to the notion that task tracking is a smell, but didn’t quite fully close that thought out as I talked about limiting work in process. If it wasn’t clear, the key point was: if you minimize work in process, the need for tracking tasks in a software tool diminishes significantly.
I handed out index cards at the outset of the session, with the intent of gathering names so I could give out a couple copies of Agile in a Flash. But that’s boring! What else could I have people do with the cards (to bolster my contention that they’re wonderful tools)?
Aha. I gave the following instructions:
“I’m looking to get live feedback during my session. On one side of the index card, draw a big fat smiley face. If you’re happy with what I’m saying, or you think I’m making an astute point, hold up the smiley face. On the other side, let’s see. If you think the believability of what I’m saying is suspect, put something down to represent that. Hmm. Believability Suspect, just abbreviate that, and write down ‘BS‘ in big fat letters. Finally, put your name below the smiley face for the drawing.”
I got a number of smiley faces throughout, but no BS cards. One guy looked like he was about to hold up a BS sign, but changed his mind–probably the one guy who hated the talk. So, my takeaway is that the silly mechanism worked in terms of getting positive feedback–but I suspect that it’s probably a bit too intimidating for most people to challenge a speaker with negative feedback.
I thank Google one final time for having me speak last Tuesday (June 6). The talk I gave was entitled “Speeding up Development With TDD.” The abstract suggested I was giving a brief live coding demo, which I did. It was intended as an introductory talk, and I’m not sure how more might have been expected given the abstract. Nonetheless, I apologize for the miscommunication.
Given a 60 minute time frame, choosing an example that works for demonstrating technique means choosing a simple class. Unfortunately, choosing a simple example suggests that perhaps this TDD thing is limited to only academic examples. I did try to explain this, using a few anecdotes about real companies getting real results from the practice.
I have learned from my public drubbing, given to me by a Google employee in a blog post. I’m always very enthusiastic about TDD, based on real results I’ve seen, but I still do try to temper the message (hence the reason I included a slide that talks about “real costs” of doing TDD). Obviously I need to provide more disclaimers in the future.
I agree with the message that the TDD community needs to work harder to provide more “real world” examples. Thank you for suggesting it.
I do have a few messages for Google.
I learned a few things from this opportunity. I can only hope Google did too.
Build something more complicated like a BTree based upon groups of integers or something, storing integers only, and interior pointers as integers and show how it can be tested? I think it’s easier to make mistakes with a BTree or a similar design than a Stack.
As well as this, it allows you to show how to structure code into the pure (more testable) and inpure parts and show how this aids testing.
I think the difficulty in TDD exercises tends to be that the exercises themselves need to be done in a quick amount of time in order to keep things going with a class. IMHO it just requires a little abstract thinking to translate those techniques and ideas to “the real world”.
Well, see you at Carfax next week. 😉
With the goal of delivering quality software, I can help you with:
Want to hear more? Call 719-287-GEEK or use the Contact Me form to the left.