According to the book PeopleWare by Tom DeMarco and Timothy Lister, they define “flow” on page 63 as:
“A condition of deep, nearly meditative involvement. In this state there is a gentle sense of euphoria, and one is largely unaware of the passage of time: ‘I began to work, I looked up and three hours had passed.’ There is no consciousness of effort; the work seems to well, flow.
Not all work roles require that you attain a state of flow in order to be productive, but for anyone involved with engineering, design, development, writing, or like tasks, flow is a must. These are high momentum tasks. It’s only when you’re in flow that the work goes well.”
When testing, it does not seem like developers are in flow. Or if they are in a type of flow, then it is very different compared to designing and writing code which in general requires more creativity. So, if a high level of flow is obtained during designing and coding, then this will make developers more productive than doing things more piecemeal by writing a method and then writing a test case for that method right after it has been coded.
Flow also has implications for pair programming. Continuing from page 63 in PeopleWare:
“Unfortunately, you can’t turn on flow like a switch. It takes a slow descent into the subject, requiring fifteen minutes or more concentration before the state is locked in. During this immersion period, you are particularly sensitive to noise and interruption. A disruptive environment can make it difficult or impossible to attain flow.
Once locked in, the state can be broken by an interruption that is focused on you (your phone for instance) or an insistent noise… Each time you are interrupted, you require an additional immersion period to get back into flow. During this immersion, you are not really doing any work.”
There are several reasons why pair programming on a continuous basis is not a good idea. Lack of flow is just one. See the link Developers work in pairs from the topic Problems with agile practices for more details.