Sunday, December 28, 2014

TDD as the crack cocaine of software

The psychologist Mihaly Csikszentmihalyi popularized the term "flow" to describe states of absorption in which attention is so narrowly focused on an activity that a sense of time fades, along with the troubles and concerns of day-to-day life. "Flow provides an escape from the chaos of the quotidian," he wrote. 
This is a snippet from the highly recommended book Addiction by Design, which not only gives you an incredibly complete overview of the gambling industry, but also insights into the human psyche which apply far outside the domain of gambling.

For me, this book was an eye-opener, with the biggest realization being that most gamblers don't play to win. They play to lose. To lose themselves. Slot machines and video poker are for many people the quickest and surest way to reach flow. It's this phenomenon that has earned machine gambling the title of "the crack cocaine of gambling."

It's not just gamblers that crave for flow though, we all do.

Some of us get up early on the weekends, to drive halfway across the country for a few hours of intensive mountain biking. Others come home after work, throw their laptop in the corner, to engage in an online shooter, zoning out for a good hour. Others will accidentally waste their entire Sunday morning solving a crossword puzzle they bumped on reading the newspaper.

All these activities meet a specific set of preconditions.
Csikszentmihalyi identified four preconditions of flow: first, each moment of the activity must have a little goal; second, the rules of attaining that goal must be clear; third, the activity must give immediate feedback so that one has certainty, from moment to moment, on where one stands; fourth, the tasks of the activity must be matched with operational skills, bestowing a sense of simultaneous control and challenge.
Machine play has all these properties. Let's look at video poker. The goal is to make a winning combination. The set of winning combinations should be easy enough to remember; they're similar to live poker. After pushing "deal" you get five cards. The player decides which cards to "hold". Pushing the "deal" button the second time will draw new cards from the same virtual deck. After the draw, you immediately know whether you've won or lost. Feedback is instantaneous. A game is over in a few seconds. Although the outcome is determined by chance, there is some degree of skill involved; it's up to you to hold the right cards.

As programmers we're lucky enough to inadvertently end up in the zone frequently. Without a doubt, it's in this state most of us do our best work. In the zone, it's constant feedback and a sense of moving forward that keep me going. One could argue that the zone is inherent to the activity of programming. I'd say that the length of the feedback loop and the size of the goals are critical and hard to maintain without working at it.

In this regard, there are a few techniques that help me reach a state of flow. At first I could get by just trying to get the code to compile or to just launch whatever it was I was working on. But once you're comfortable with a code base, getting it to compile isn't much of a challenge, and having to start your application to get feedback gets old real quick. Most often it's TDD that helps me get there these days. You start of with a failing test, your mission: to make it pass. The rules are simple; when your test goes from red to green, you're allowed to move on. It's important that tests are fast to be able to give you that immediate feedback. How fast? Fast enough for you not to lose focus. It stands for itself that the fourth precondition is met too; you're writing the code, doing your best to bend it your way.

When TDD is sold as a productivity booster, it are often strengths such as automated continuous validation of correctness, partitioning of work in smaller units and cleaner and better designed code that are used as arguments. While these are valid arguments, it's a shame that the power of TDD as a consistent gateway to flow gets neglected or undersold.

Getting in the zone by yourself is one thing, getting there surrounded by a group of people is often out of the question. Here Event Storming has helped me out. Small goals; what happens before this event? Rules; write the previous event down on a yellow post-it. Feedback; once the post-it is up, we see that we're reaching a better understanding of the big picture. Control and challenge; you're the one searching for deeper insight, writing and putting up the post-its.

The activities that get me in a state of flow are the ones that I enjoy the most and which enable me to output my best results. If you reread the four preconditions, and assess the things that get you going, you might learn that the same goes for you.


  1. Provocative title, was not disappointed. Why not harness our innate impulse to play to make us more productive! Thanks.

  2. This is my aha moment of TDD. Flow is the word. Thanks.

  3. TDD, I knew Crack Cocaine, and you're no Crack Cocaine.

  4. "Some of us get up early on the weekends, to drive halfway across the country for a few hours of intensive mountain biking"

    Only possible if you live in a very small (and mountainous) country.

  5. Woah, I never stopped to consider my TDD as a tool to survive the ventures of programming, I got there when I got lost in a swamp of legacy crap.

    But now that you say it, sometimes the T is more exciting than the D, or sometimes the T is crap and you get lost in the D. Powerful words, thank you.

  6. "TDD is addictive. Red-green-refactor is an addictive flow" - @DHH "I am the poorest drug dealer on the planet" @KentBeck @16':43"

  7. "I think you (@KentBeck) are very crafty at that. And I think that the red-green-refactor flow is ingenious in that sense because it does give a lot of good feelings, it releases a lot of dopamine for a lot of programmers." @DHH in

  8. "being in the zone is a drug, and as you build up tolerance, getting the next 'high' becomes more and more difficult. This may explain why programmers move on to management or other pastures as they get older" - @ploeh in via @GitteTitter

    1. "Forget the zone, and learn to work in small increments of time." - @ploeh in in via @GitteTitter

  9. @sf105 @JefClaes @KentBeck @unclebobmartin disagree on flow, which I've come to view as seductive.

    1. "Wray hypothesises that Pair Programming may help to manage this addiction by keeping us honest. I suspect that Test-Driven Development also helps by smoothing the flow, removing the Variable Ratio effect" 2/2 @sf105 in

  10. "It's possible that I'm the most impatient programmer on earth; I want my feedback to be so fast that I can't think before it shows up. If I can think, then I'll sometimes lose attention, and I don't want to lose attention. I aim for test feedback in 300 ms, from the time I press enter to the time I have a result. - Gary Bernhardt in

  11. TDD gives us the benefit of focus and lowers stress.

    See below (I have turned excerpts of Martin Fowler's afterword to Kent Beck's 'Test Driven Development by Example' into bullet points):

    * Programming is hard.

    * It sometimes feels like trying to keep several balls in the air at once: any lapse of concentration and everything comes tumbling down.

    * TDD helps reduce this feeling, and results in rapid unhurriedness (really fast progress despite feeling unhurried).
    This is because working in a TDD development style gives you the sense of keeping just one ball in the air at once, so you can concentrate on that ball properly and do a really good job with it.

    * When you are trying to add some new functionality, you are not worried about what really makes a good design for this piece of function, you are just trying to get a test to pass as easily as possible.

    * When you switch to refactoring mode, you are not worried about adding some new function, you are just worried about getting the right design.

    * With both of these activities, you are just focused on one thing at a time, and as a result you can concentrate better on that one thing.

    * Adding features test-first and refactoring, are two monological flavours of programming.

    * A large part of making activities systematic is identifying core tasks and allowing us to concentrate on only one at a time.

    * An assembly line is a mind-numbing example of this - mind numbing because you always do the one thing.

    * Perhaps what test-driven development suggests is a way of breaking apart the act of programming into elemental modes, but avoiding the monotony by switching rapidly between those modes.

    * The combination of monological modes and switching gives you the benefits of focus and lowers the stress on the brain without the monotony of the assembly line.


  12. What is the overlap between the 'zone', which you consider the programming equivalent of 'flow' (
    and Robert Martin's 'Flow Zone' ?

    1. Good point. I do think TDD allows for taking a break and retrospection which should avoid getting lost (for too long)?

    2. Now I wonder: may the addictive nature of the TDD cycle prevent us from giving importance to the "back to the drawing board" moments? After all if we're there playing at the slot machine we don't even want to get up from the chair, forget about reconsidering design decisions on board or on paper...
      Incidentally, I found pair programming affects the flow positively as one of the two people can protect the other from interruptions; maybe it has a similar effect of intentionally breaking the flow of the other person if he gets stuck.

    3. I try to time box the zone using pomodoros.