I’m working on writing up a few handouts I can use in a TDD class (and a few other places). There are a few drawings I keep doing and I’m trying to replicate them so I can refer to something.

Problem is, with many such drawings, the observation of the creation is as important as the end product. I’d like your feedback/recommendations (or links to better pictures). I’m curious about at least two things.

• What does this picture suggest to you or what can you draw from it, if anything?
• Do you think this would be better served as a series of pictures showing the build-up?

Thanks for your feedback.

Dale Emery recently wrote a lovely article that has the same name as this blog. This article is really quite good. It makes the point that writing acceptance tests is writing software; and so the same principles of cohesion, coupling, DRY, etc. apply.

The only problem I had with Dale’s article, is that he used the wrong tool to demonstrate his principles. So I’ve created a video to show you how to apply Dale’s principles using FitNesse. (See below)

This week I spent 2 days with my friend Luke Hohmann getting trained in the use of Innovation Games®. Innovation Games® are a class of so-called serious games that use metaphor and experiential learning situations with an end-result-goal of developing actionable information. (This is my current way of describing them anyway.)

During one of these games I played the role of a facilitator. There were 2 of us facilitating, three “customers” being interviewed and 4 observers.

I saw this cartoon in a tweet today. It’s the story of how a boss corrupts the work of a professional. It’s a funny cartoon, and a sad story that happens all too often in our profession. But who, exactly, was at fault?...

There has been an increase in interest in Software Katas of late. What is all this buzz about, and why might it be important?

I just got back from my third time at the AYE conference and it was another great time. I had a real eye-opening experience on Wednesday and it had to do with how I interact with customers, QA and even developers. Pretty much anybody taking a class or starting a project where I am involved.

I was going through some old files today, and I stumbled upon some acetate slides from 1995. They were entitled: “Managing OO Projects”. Wow! What a difference fifteen years makes! (Or does it?) ...

Update 12 hours later.

I’m not very proud of this blog (or as one commenter correctly called it “blart”). It is derisive, sneering, and petulant. It is unprofessional. I guess I was having a bad morning. I slipped. I didn’t check with my green band.

So I apologize to the audience at large, and to Cashto. You should expect better from me.

I thought about pulling the blog down; but I think I’ll leave it up here as an example of how not to write a blog.

The twittersphere has been all abuzz today because of something I tweeted early this morning (follow @unclebobmartin). In my tweet I said that I hand-roll most of my own mock objects in Java, rather than using a mocking framework like mockito.

The replies were numerous and vociferous. Dave Astels poignantly stated that hand-rolling mocks is so 2001!

So why do I roll my own mocks?

I’m teaching a TDD and Refactoring class this week using C++. Since I had not recently wrote the bowling kata in C++, I figured it was about time to do it again.

Unlike the previous Scala version, this one only addresses the happy-path. I do not consider throwing too many balls or scoring too many pins in any frame. However, having just written this in Scala, I’m sure I could do something similar in C++.