For the most part, that was the message at the “Acceptance Testing: Just Say No” by James Shore Meetup tonight at the Shopzilla.com offices in Santa Monica, CA. James structured the talk as though it was a “fill in the blanks” Anonymous meeting (you know, Alcohol Anonymous, Sexaholics Anonymous, etc). The concept of Acceptance Test Driven Development (ATDD) Anonymous was actually pretty clever and came across pretty well, at least to me.
As for my general notes on the talk, he started with some background on the ATDD area focused on Ward Cunningham and his creation of Fit (aka, Framework for Integrated Test) as an original unit test tool that was co-opted as an ATDD tool. Fit spawned Fitness which is a wiki-based table tool, again, co-opted as an ATDD tool; another TDD tool mentioned was Cucumber.
James noted that it’s unfortunate that its easier to quantify the costs of co-locating teams than quantifying the hidden costs of not co-locating teams, but that in the end it’s better to co-located teams for success. For anyone who’s worked on remotely located teams (me being one of those folks), this doesn’t come as a surprise. I’ve found that my more successful projects, products, and roles were ones where I was co-located with customers and developers.
James mentioned four types of bugs and how to work to eliminate each. Requirements errors can be eliminated (or shall I say reduced) by having customers co-located with the product/development team. Programmer errors can be reduced by using Test Driven Development (TDD). Design errors can be reduced by continuous incremental design, by doing constant code refactoring, and by building in slack each week to do so. Systemic errors can be reduced by performing an RCA on all errors identified. More on these types of errors in a bit.
Now, how would a team work to reduce these four types of bugs? In serial or parallel fashion? Good question, so I asked James. His response was to take a large chunk and just do it, failing that go with TDD first. Outside of his own book and Michael Feathers’ referenced below, a good resource for guidance on adopting TDD are his Let’s Play TDD webcasts that go through real world examples as well as his chapter on TDD in his book. His experience seems to point to the Kaizen approach not working for TDD.
James stressed the importance of cultivating an attitude of “bugs happen to other people” which is an attitude that makes me drool. Having a team that thinks & acts like that? Now that’s sexy. (I know, I know, I’m a nerd.)
The best way to solve co-location issues (i.e., having remotely located teams) without co-locating is via expensive video conferencing equipment or better by plane flights to meet in person. Reading between the lines here is that you can spend all the time & money to get close to a co-located feeling, but until you’re actually co-located you won’t get all the benefits of such a work environment.
In terms of helping solve the issue of eliminating or reducing bugs on legacy software, James recommended Working Affectively with Legacy Code by Michael Feathers. And to read more in-depth on James thoughts on reducing the four types of bugs, check out his blog post on Alternatives to Acceptance Testing.
In short, combine TDD with great customer collaboration and co-located teams.
Leave a Reply