The Diamond Kata Workshop: TDD, Anti-IF, and Emergent Design

Next week, I’ll be running a Workshop on the Diamond Kata.

The decision to do this kata comes from a LinkedIn post by Matteo Vaccari. If you will follow my comments to that message, you’ll understand why I generally don’t like katas. Even less so the solutions that I have seen so far.

In particular, reading Matteo’s message, I discovered that various agile gurus had determined that this particular kata can’t be tackled with TDD. Apparently, it’s a special case: it requires anticipatory thinking. You’ll find more information on this point in the workshop introduction.

The Challenge

So, initially, I accepted the challenge to show that TDD can actually guide the solution of that kata without anticipatory thinking. Doing TDD in the sense of doing emergent design. The application of the Anti-IF programming principles would help flatten the cost of change. This is our end goal.

I thought it was simply about developing a basic feature, but as you will soon understand, the context turned out to be more interesting than expected.

The Evolution of Agile

You should know that since I publicly closed with Agile – I think at a conference in 2008, though I might be wrong (someone who followed my talks may correct me) – I haven’t followed that world closely. That was my world, having been one of the pioneers of eXtreme Programming (XP). 

In 2008, I retreated into my “cave,” developing new methods for better software design. It was tough work that I had to fund myself. Despite the support from participants in my courses and mentoring programs, there was at least one occasion when I considered an alternative path. In 2022, I left my “cave” in Berlin for a few months. LinkedIn showed me a startup looking for an Agile Coach, and I thought, why not give it a try?

I’ve always considered the role of Agile Coach unnecessary and possibly harmful. There is no coach in XP, so why should there be one in Agile? It’s the team that makes decisions and learns autonomously. However, I thought that if they gave me enough autonomy, I could turn that role into more of a mentor. In any case, when it comes to funding your own research, you can’t be too picky. During that experience, I realized many things: that the Agile of 2022 was not the Agile of 2000. Most importantly, I came to understand that almost no one was doing software design anymore.

It was the Diamond Kata that pulled me out of the cave this time, at least for a few hours. After Matteo’s post, I wandered around Linkedin, guided by the links shared by my mentees. I saw processes hailed as agile that propose incorporating multiple TDD cycles (acceptance, component, and unit). Apparently, TDD alone is no longer enough. Katas considered successful by developers were solved with an alarming number of IF statements per square inch. Iterative processes that lean towards waterfall were mistaken for adaptive processes.

In the end, I prefer my cave.

But something clicked. I felt the urge to do something – call it nostalgia. I liked the idea of showing people how we worked in XP in 2000. Why there’s no need for ATDD, BDD, or multiple nested TDD cycles. TDD is just enough. TDD as a software design tool to help abstractions emerge.

TDD Movements

It’s 5 p.m. on October 9th. It’s hot in my new cave in Dubai. I’ve been working on the Diamond Kata for a few days. After a few initial steps, I started taking notes on my actions and decisions. It’s 190 pages now and I expect at least 250 pages when the kata is completed.

Initially, I was describing the various steps to track them and create the workshop slides. Then, reading them again every day over breakfast, I noticed some recurring mental patterns and began to mark them. Creating a system of TDD Patterns which I now call “TDD Movements.”

I’ve noticed that outside the cave, many developers place a lot of emphasis on Red-Green-Refactor Cycle. Let me clarify: these are not the movements that fill my notes.

The Red-Green-Refactor Cycle of TDD is to those TDD Movements what knowing how to move chess pieces is to actually playing chess.

It’s useful, important, but it doesn’t replace the depth of decision-making required by emergent design. Yet, in many blog posts and videos, this mantra of Red-Green-Refactor seems to be touted as a cure-all for software. One cycle after another, following Red, then Green, then Refactoring anyone can produce… a kata solution packed with nested IFs that would break records. Clean nested IFs, of course.

Forget the Red-Green-Refactor totem. The cost-of-change curve doesn’t flatten by stuffing Clean IF Code into your classes. TDD is about finding abstractions able to flatten the cost-of-change curve.

The Program

In the workshop, I’ll split the work into two parts.

• The first part will focus on TDD as I learned it, showing the mental movements that I see systematically repeating to have abstractions emerge, and the Anti-IF movements to flatten the cost-of-change curve.
• The second part, instead, will focus on more advanced—no, perhaps it’s better to say more powerful—design movements. Showing how to evolve one’s design towards more effective handling of the cost of change.
• I’d like to show some challenging steps and to solve them.
• I’d like to show the cost per story and assess the outcome together from an economic, entrepreneurial perspective.
• I’d also like to stimulate debate and hear from those who’ve tried other practices, to understand together how we can improve.

Ready to Program

I hope this workshop will be a breath of fresh air for those who want to see the true potential of TDD and Anti-IF Programming, far from the distortions accumulated over the years.

I’d like the participants to walk away with a clearer, more practical view of how to apply TDD effectively, to achieve understandable and robust design without compromise.

And yes, it’s possible to write code without IF statements. But the point isn’t to write code without IFs, it’s to defuse the IF strategy.

See you on Wednesday, October 16th.