I heard a good story on one shop where they actually had a KitchenSink class in their codebase to dump things they really couldn’t define a context for. The point was they were at least being transparent about their failure to find a better place to put something.

According to xUnit Test Patterns:

The Ruby-based RSPec kicked off the reframing of TDD to EDD (example-driven development), and the Java-based JBehave followed shortly afterword.

– xUnit Test Patterns pg 33

Actually JBehave predated RSpec by a few years. I remember going to a talk by Dan North of Thoughtworks on JBehave in March of 2005. He presented with examples of JBehave and explained how it got people away from thinking about tests. The very next year at SD West 2006 I attended a half day tutorial by Dave Astels on RSpec. It was still pretty early for RSpec at that point about 0.5, but it was already pretty nice because Ruby is just a lot easier than java for writing a behavior driven DSL.

A bit of poking around reveals JBehave actually dates back to 2003 when Dan North started working on it in at Thoughtworks. I think the issues with making nice DSLs in Java probably led to the much larger success of RSpec in the Ruby community and led to the thinking that JBehave came after.

A good PM should annoy a developer some of the time.

It’s like Java Posse for Rails Developers only shorter, funnier, and tightly scripted.

The Rails Envy guys, Gregg and Jason, have put together a great podcast on current Rails news, packed it into 10 minute episodes and spiced it up with humor. You probably already know them from their parodies of the Mac PC ads with Rails versus Java, .NET, Coldfusion, etc. If you haven’t added the podcast to your feed and you keep any track of the Rails community it’s worth adding to your weekly podcast menu.

A core part of Scrum and many other Agile methodologies is ‘inspect and adapt.’ Retrospectives are a key practice in reviewing the last iteration. You toss up on stickies or a white board the ‘What Went Well’ and ‘What To Look Into.’

Diana Larsen held a session at the end of Agile Open California on retrospectives and suggested two key ideas on how to take action after a retrospective:

• Pick one or at most two things on the list to work on for the next iteration.
• Only pick something that at least one person in the room has the energy to take on. If no one has the energy for the next iteration don’t try to force change.