Agile 2011: Live Speaker Feedback

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.

Open Note to Google

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.

  • Tests == specs. Ok, I’ll concede that this is silly as a literal comparison. I presented this notion as one of my “mindsets,” something that helps me think in terms of some of the goals I should be able to get out of them. The word “mindset” was on the title of the slide I presented.
  • If it’s not testable, it’s useless. Once again, this was on the slide called “mindsets.” It’s a direction to head in. It’s intended to get you to think in the opposite direction, instead of making excuses why not to test. I’m sorry, I can’t back down much on this statement. The fact that Google can ship code that just happens to work suggests that maybe they’re better programmers than the rest of us. But this notion that it’s ok to design most code in a way that it can’t be tested is ludicrous. Note that I never said that every test had to be a unit test, or even automated. But the more of them that are, the better. Most code can be unit tested if designed well. Most.
  • Your code is just like everyone else’s code. I’ll take the Google challenge, and bet that I could take almost any Google system (except for the few where they’re doing TDD well), and pare it down to 2/3 or less of the original amount of code, while at the same time dramatically improving its maintainability.
  • Every company thinks their systems are uniquely complex. I’m willing to bet, however, that the bulk of the requirements for Google systems are probably no more complex than systems anywhere else. I heard the excuse at Google that “some things are just too hard to test.” Every time I hear similar excuses, I’ve seen poorly designed systems. Certainly, there will be small amounts of my system for which coding unit tests outweighs the benefits. But if any significant portion of my system is too hard to test, then I’m doing a poor job of managing complexity using basic OO design concepts.
  • Someone in the audience that suggested popping off a stack was a good way to test creation of a stack. This is a perfect example that demonstrates complete misunderstanding of what TDD is about. I said (it’s on the tape) that coding such a test into “testCreate” was inappropriate, that it represents different behavior and should be placed in another test. I probably wasn’t clear enough on this point. I never dismissed the thought in order to maintain a “script.”

I learned a few things from this opportunity. I can only hope Google did too.


Maybe it would be worth picking up a different example that is more complex and easier to get wrong.

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. 😉

– James