Here are the slides (as a PDF file) for the Intro to Test-Driven Development speech that I gave at the SCQAA meeting last night. I haven’t seen the speaker feedback forms yet, but based on the comments from people walking up to me afterwards, it was an effective speech. In particular, everyone loved my grand experiment to demonstrate TDD — without requiring any programming knowledge — by having the audience break up into teams and write limericks test-driven.
If enjoyed this speech, then you might also be interested in materials from other speeches that I’ve given in the past. You can find them on the Downloads page.
A front page story in this morning’s USA Today talked about airline safety and how improper simulator training for pilots often causes accidents. Flight simulators, no matter how impressive the technology behind them, are not perfect representations of actual flight. Yet, the airlines rely on them for the bulk of new pilot training. So, under certain circumstances, pilots take the wrong actions because they react to how the simulator works, not to how the plane actually works. This is proof that the old adage “practice makes perfect” isn’t quite right. The saying ought to be: “practice make permanent.” Practice the wrong things, and you just get good at doing the wrong things. Continue reading Taking the Stick →
Do you plan on attending the San Diego Code Camp the weekend of June 26-27? If so, please consider voting for the session I submitted, “Getting the Most out of Pair Programming.” To vote, go here: http://www.socalcodecamp.com and log in (or register), then click on the Sessions tab, scroll down the the G’s (alphabetical by title), and check the box next to the “Interested” count. Thanks.
Here’s the Session Description I Submitted: I’ll start with a 10- to 15-minute presentation of my experiences with pair programming going back 10 years Continue reading Pair Programming Roundtable at SD Code Camp, Interested? →
One of the reasons that pair-programming works so well is the same reason that brainstorming is such a powerful technique in a group setting. Pairing basically amounts to an endless stream of mini-brainstorms between the two partners. I swear that whenever I pair with someone, we’ll write code that is easily three times tighter and cleaner that if I had written it alone, and I think the brainstorming aspect has a lot to do with why.
In formal brainstorming, you start with an initial pool of ideas and build it up by pushing the boundaries, piggy-backing on the previous ideas, and inverting or negating the previous ideas. It’s the job of everyone to be contrariwise with each other — to keep asking “What if?” and “Why not?” In pair programming, a similar thing happens. It’s the job of the person who’s riding shotgun to be looking at the bigger picture (while the one who’s driving is focused more on the task at hand), and this is what makes for the same kind of contrariwise/collaborative atmosphere as brainstorming.
a blog by Craig L. Jones, Software Agilist