Test Driven Development and Flow

Last week I was doing a training session in Melbourne, Australia. I had an especially energetic and interested group of people to work with. In basic agile training, a 1.5 day workshop, I introduced Test Driven Development very briefly, cutting it short because we were going to spend the whole next day doing a TDD lab. I mainly gave a sales pitch including the statement that, after decades of writing software, learning TDD made me a better programmer by at least a factor of four. That is a pretty fuzzy claim, but I made it for effect.

I always make it a point to do a retrospective at the end of any lengthy training session. During the retrospective with this group one developer made a strong statement of skepticism at my claim. He said that it seems to him that writing a test first was surely going to interrupt his flow of writing code and that could not be a good thing. I took this as a challenge and thought about it a bit overnight.

The next day I started my TDD workshop as usual with a presentation and a short demonstration. At the end of the presentation, I veered off a little from my usual script to talk about flow. It went something like this.

In the old days, and maybe these days for a lot of people, there was this concept of a programmer’s nirvana where you get into “the flow”. The flow is an altered state of mind, likely fueled with mass quantities of caffeine, in which code just flows from your fingers like water from a mountain stream. You get a creative high and problems just melt away before you. There is no looking back, no stopping to document, a feeling that nothing is too hard to handle. The flow is, of course, a solitary state. It often comes at a time of stress, like near a deadline (before or after). It is often a heroic act, a single-handed response to a great need to create code quickly. It often comes late at night.

I have experienced the flow more than once. Sometimes it happened at work. Sometimes on my own time, working on some personal project. Sometimes it came at the expense of other things, like familial duties. It is the polar opposite of the black hole where you seem to spin your wheels against some problem with no hope of resolution. In the flow, stuff just works. It is great.

Sometimes, maybe most of the time, the stuff you produce when in the flow does not stand up to the light of day. It may be hard for others to understand. It may be hard for you to understand even though you wrote it. This is because it had a logical consistency while you were in that altered state that cannot be recovered afterwards. But sometimes the results are just fine.

I described this flow state to the class, in fewer words, and then compared it to the TDD rhythm. Unlike the flow state, the TDD rhythm has a defined structure to it. It is easy to get into by just following the pattern test-code-refactor. The flow state has no such structure. It is unpredictable and amorphous. The TDD rhythm can be interrupted and resumed with no harm to progress. All you need to do is restart the rhythm with the next test. The flow state usually cannot be resumed once it is stopped to do anything more than make another pot of coffee. The TDD rhythm includes reminders of what you did – in the form of unit tests and well-named class methods. It also tends to produce code with small units. The flow state can produce elaborate solutions and opportunities that may not be necessary. It is undisciplined and that usually shows in the quality and readability of the code.

The TDD rhythm results in confidence built of many successes (the tests). The flow state also contains confidence, built upon creative energy and maybe caffeine. Is TDD less creative? I don’t think so. I like the confidence I get that the work I just did is clean, solid and easy to read. And the TDD rhythm can be shared. It works just as well for two people as one. That is true when pair programming. It is true when handing off a task to someone else. The flow state can be shared to some extent, more in design than code, but it is mainly a solitary affair.

Best of all, I can get into the TDD rhythm any time I want to. The flow state was a rare event for me. I could get into a light trance any time I was left alone, but the results were not consistent. Rarely did I reach the peak experience. The TDD rhythm is much more predictable and repeatable. Of course, this is just my observation from having been in both states. Your experience may be different.

So we did the TDD workshop down under and I finished with a retrospective. I asked my skeptic what he thought now. He said that he really liked the small steps and the constant validation. And he liked that he could stop at tea time and quickly pick up where he left off. So I think he was swayed to the good side of the flow. I’ll ask again next time I go down there. (That is a hint to my hosts.)