Towers. Last year I developed Towers [PDF], a rectangular version of Kris Burm’s hexagonal game Dvonn. Now, Burm is a genius, and Dvonn is a fascinating game just the way it is, and the world doesn’t really need a watered-down rectangular version of it. But I wanted a board game to use as the basis for a sample application for my Test-Driven Development workshops, and hexagonal grids are just too much to ask of workshop participants. So Towers was born.

My goal was to code the first few basic features of the game myself, such as moving one tower onto another. And I would include some smelly code for participants to refactor. Over the course of the workshop, participants would write additional features—determining which moves are legal, detecting the end of the game, and so on.

That was my intention.

I started writing the code, and worked on it in rare spare moments over the last eight months. As of a few weeks ago, I’d gotten the code as complete as I needed for my workshops, and was spinning my wheels, dabbling in various refactorings for my own amusement.

GOOS. As I was spinning, a conversation suddenly blossomed in the Growing Object-Oriented Software (GOOS) Google Group, associated with Steve Freeman and Nat Pryce’s terrific book of the same name. Someone had dropped a note pointing to Brain Swan’s provocatively titled presentation “Mocks Suck.” A fascinating dialogue ensued, led by Steve, Nat, Brian, Joe Rainsberger and others.

As I watched that conversation, two things stood out for me. First was that the “tell, don’t ask” principle (aka The Law of Demeter) kept coming up. Second was the repeated assertion that JMock’s strictness (its rejection by default of any method call you didn’t tell it to expect) was not a damned nuisance at all, but actually a good thing, because it points to problems in the code.

Though I’d heard both of these ideas before (I first read about the Law of Demeter in 1990 when I was writing C++ code), and applied them half-heartedly, I’d never given them my full attention. But Steve, Nat, and Joe are all really smart, and I’d learned much from them in the past. So when they all repeated these ideas within a few hours of each other, I sat up and took notice. As they explained their approach to mocking, I began to see that strict mocking and “tell, don’t ask” were at least more nuanced than I’d thought, if not more powerful.

The Itch.I got the itch to apply these two “new” ideas mindfully. And I added a third idea that I had been practicing for a while, but which suddenly made more sense in light of the GOOS conversation: Develop applications from the outside in.

Suddenly I had a new intention for Towers. In addition to writing a sample application in my workshop, I could also create a workshop for myself, an opportunity to apply these three ideas and see what I could learn.

So I began applying “tell, don’t ask” to my existing Towers code. After a few days of that I began to feel lost and backed off. (You may follow that trail from the clearly marked commit on Jan 12 if you wish. I haven’t the heart.) I spent a day away from the code, then decided to start the whole app over in a fresh repo.

A Blunt Instrument. Several coding-hours into my third take, I found myself struggling to configure three different mocks for one class I was testing. After I’d thrashed a bit, something hit me like a can of Spam to the forehead: This was one of those situations Steve, Nat, and Joe had talked about. The problem was not that the mocks were difficult to set up. The problem was that my simple class required three collaborators.

A Blunter Blunt Instrument. A few commits later I’d fixed the problem, and was excited by what I’d learned. I tweeted (in a way that was perhaps easy to misinterpret as criticism of JMock): “Using JMock for the first time. Noticed 3 mocks in one test. Ugh. Started refactoring. Ended up with one dependency, no mocks.”

Within minutes, Steve replied “Post example code please?” Seconds later, Nat added, “Are you going to write up your experience?”

I promised to post some code, but hesitated about writing up my experience. “I don’t know yet,” I said. “I’m too new with ‘tell, don’t ask’ to have a feel for what I’m doing.”

Then Yves Hanoulle hit me with this blunt instrument: “Why is being new an excuse for not writing down?”

Dammit, he’s right. Double dammit.

So I started writing a short blog post about what had happened in the “three mocks” incident. As I scoured my (frequent) git commits to find reference points for my blog post, I found myself studying my process. What had I done? What had my reasoning? What had the results been? Then I discovered that there were things to learn from even earlier in this hours-old project, starting with my very first decision, my choice of “walking skeleton.” And suddenly I was learning from the process of writing.

The Thing. And that post turned into two. And then I thought I could make it a series (just in case I learn anything else, and just in case that’s interesting to anyone). And then I needed to write this introduction. And now it’s becoming a thing. (Dammit, Yves!)

So this post is my introduction to the thing. Two more posts are in the works, each nearly complete. One describes the “three mocks” problem. The other describes the earlier code and the “walking skeleton” problem. Beyond that, who knows?