Jeff's Blog
Musings about software development, Java, OO, agile, life, whatever.Note: This blog is no longer active. Please visit Jeff's current blog instead. Unfortunately, any new comments entered cannot be retained or displayed. If you feel strongly about a blog entry, please contact us.
Olof Bjarnason, a poster to the Yahoo! test-driven development list, has compiled a list of TDD demonstration/exercise problems. The list currently appears at http://sites.google.com/site/tddproblems/all-problems-1 (thanks George!).
TDD demos are often dismissed as trivialities. A frequent claim is that they're not "real-world" enough, suggesting that TDD can't scale. I've moved through a few different preferred demos, but I'm always seeking out new and better ones. Currently I prefer a multi-map (key -> list of associated values). I've used a multimap often enough in "real" applications, it's a short demo, and it covers all of the important bases in demonstrating TDD rudiments. The only downside is that a similar construct already exists in Apache Commons.
So what are the important bases to cover? I think a good first TDD demo should have the following characteristics:
| Can be demoed in 30-45 minutes | If you weren't demoing, you'd be able to test-drive the solution in 10-15 minutes. Any shorter of a demo and you tend to blow past much of your audience. |
| Has some "real world" relevance | This is why I don't demo the bowling game |
| Isn't too trivial | Stack is just a bit too small |
| Solution requires no contrivances | For example, you shouldn't have to say "we'll use some dummy data here" |
| Allows for a continually incremental solution | Green bars come every few minutes (reinforces "red first"), after at most 3-4 production lines of code |
| Requires no major intuitive leaps | This rules out, say, the Roman numeral conversion, but doesn't mean you can't use that for a later lesson. |
| Solution provides continual opportunities to incrementally refactor both tests and production code | An overloaded interface on multimap (size & isEmpty) can help bring out a key point here. |
| Can demonstrate the choice to test behavior over testing methods | Provokes a discussion around test method naming and potentially BDD concepts |
| Can emphasize "fake it 'til you make it" | Hard-coding forces more tests, and also allows faster green bars. Specific solutions -> generalized solutions |
| Includes at least one exception-based (negative) test | Opportunity to discuss test-driving alternate paths, as opposed to including them as an afterthought |
In Scrum, those "not accountable for deliverables" (emphasis added; see Jeff Sutherland's blog) do not get to talk during certain meetings. Pigs (product owners, ScrumMasters, and "the team") are accountable for the success of the project. Everyone else is a chicken, because they're not accountable for the project. Their opinions are distracting and thus damaging to the project.
Thus customers--people who ask for and pay for the product--are not part of the team, nor are the people who manage humans on the team. In Scrum, these people are absolutely not part of what we're trying to accomplish, and they are to be silenced during parts of the development process.
Of course I understand why the rule exists. There's always a loquacious manager or sponsor who wants to hear their own voice, or worse, insist that the team work "their" way. Understandably, we should want to minimize such distractions.
Unfortunately, the remedy goes too far, substituting command and control for the core agile value of communication. The rule is borne out of excessive personal bias: In the above-linked blog post, Sutherland says, "Whatever we call them it should have a negative connotation because they tend to sap productivity. They are really suckers or parasites that live off the work of others."
Gee, how do you really feel?
Some distaste between management and development is normal, but this stance isn't at all helpful. Knowing that deeply caustic bile is part of the foundation of pigs and chickens only affirms my belief that it's a damaging practice.
XP embraces the wonderful value of courage. The simple XP solution would seem to be: Ask the disruptive people to stop. Talk about it. If you can't figure out how to do that, you have more serious problems that a contrived rule is not going to solve.
People are not chickens. Calling them such is demeaning, even if you have a cute, cloying story to back up your attempts to control. A simple statement or two can make things clear: "This meeting is intended to help ensure continual progress on our commitments to delivery. Discussions around that are welcome, no matter who you are. Attempts to be a back-seat driver should be taken offline to our Scrum Master (tm). We'll let you know if you're detracting from our goals."
Ultimately, it should be obvious that any rule that silences a whole class of people is not in the spirit of agile. We should welcome contributions from those even remotely involved in our efforts. If they come at the wrong time, we can gently ask them to talk about it later. Sometimes the best ideas come from those who are not accountable.
This posting won't keep people from insisting on the rule of pigs & chickens. That's ok. The next time someone calls you a chicken, let them know that there is a new animal in agile. It's the ass. The ass is the person who dictates how things must be. They are stubborn, controlling animals. Perhaps the best thing to do with an ass is to give it a good swift kick.
I know that a team is on the right track when they:
- deliver on the majority of their commitments each iteration, and at most a portion of one story is incomplete at the end of an iteration
- deliver stories every 1-3 days, on average, throughout an iteration
- can tell you relevant statistics about the code base, for example, how many unit tests are there and how long they take to run
- commit to improvement, and deliver on that commitment, without having to be told--they just do it
- don't fear open conflict
- can be seen talking about the code
What other indicators do you have?
Archives
February 2004 March 2004 May 2004 September 2004 October 2004 January 2005 February 2005 September 2005 October 2005 November 2005 December 2005 January 2006 February 2006 March 2006 June 2006 August 2006 January 2007 February 2007 March 2007 April 2007 September 2007 October 2007 November 2007 December 2007 January 2008 February 2008 March 2008 April 2008 May 2008 June 2008 July 2008 August 2008 September 2008 October 2008 November 2008 December 2008 January 2009
