Group Flow in Software Development

In The Clean Coder, Robert C Martin writes about being in the Zone:

Let me be clear about this. You will write more code in the Zone. If you are practicing TDD, you will go around the red/green/refactor loop more quickly. And you will feel a mild euphoria or a sense of conquest. The problem is that you lose some of the big picture while you are in the Zone, so you will likely make decisions that you will later have to go back and reverse. Code written in the Zone may come out faster, but you’ll be going back to visit it more.

Image: A developer listens to music to get in the zone

The Zone is known by many other names in many other contexts. The most general term for this state is Flow. There is quite a big body of research surrounding Flow. Flow can be reached when certain criteria are fulfilled:

With these criterea in mind it is obvious why late-night coding with music leads many programmers to the Zone.

Being in Flow has some very positive consequences: this is where you learn the fastest, and where you are the most productive, working with what is already known. “You will write more code in the Zone.”

As Robert C Martin points out, however, programmers in Flow often forget to communicate. They are the most productive with the knowledge at hand, but they cannot know everything. Ultimately, software development is more about taking the right decisions than taking fast decisions (or writing code fast). The right decisions are found through discussing the domain with colleagues. Being in the zone leads to a worse product (no matter how good the code is).

Being in Control #

Flow can only be reached when a programmer is adequately challenged for their level of competence. But if either of these variables, challenge or competence, are changed the programmer will slip out of the “danger zone” for Flow and into some other area.

Image: Flow states, from Apathy to Flow. Above Flow, we see Arousal. Below Flow we see Control.

When you are challenged too much for your level of competence, you move into the area called Arousal. This is what people who practice extreme sports experience, and why it is so addictive.

If the level of challenge is reduced, however, you will move into an area called Control. Being in control means being comfortable with the work, but not quite yet bored.

Being in Control means that the developer will not forget their surroundings, they will be aware of everything that goes on around them, and still interact with co-workers. That is one solution to the problems introduced by being in the Zone: avoid it by breaking down problems into smaller, easier ones.

Group Flow #

Groups of people can go into a state of flow together. This means that they are each challenged adequately, but also that they are challenged adequately as a group. All the previously mentioned conditions must also be true for each member of the group.

In group flow, learning and productivity will increase massively, too, but in this case communication and sharing of knowledge is not lost.

A common example is taking up a problem for discussion around a whiteboard. Allowing the developers to draw out the problem and communicate around it often creates a new, shared state of mind that improves problem solving abilities, and more quickly reaches a better solution.

Group flow puts up two further requirements that do not exist for individual flow:

These are both preconditions that are not present when a developer enters the Zone. A developer entering the Zone focuses on a problem on their own. They don’t share feedback with others, they have only themselves to share a frame of reference with, and they react based only on their own knowledge.

The requirements for Group Flow are interestingly fulfilled in Pair Programming:[2] two developers sit down, their screens show the same thing (so they get the same feedback) and their keyboards and mice do the same thing. They both work on the same problem, but can choose how to split the work (often one person writes code, while the other talks).

Image: Mob Programming

A relatively new, or at least significantly less well known, practice is that of Mob Programming. Here, a group of people — for example, 5 — all work together, looking at the same screen (often a projector screen). One person writes code, one person describes the code that should be written, and the rest take up positions of researchers.

Both Mob and Pair Programming recognize that the hard thing about programming is not writing the code, but finding the best solution for the problem. Users of both practices report seeing that developers learn good practices more quickly, simply by talking to programmers with more or different experience. Both Mob and Pair Programming report massive performance boosts for the teams that adopt these practices.

This is the second way to go around the issues of the Zone: bringing others with you.

I am not saying that Pair Programming or Mob Programming are silver bullets that should be used everywhere, but knowing that they work, and understanding why they work is important when designing a development workspace.

Notes #

  1. Being motivated by the subject matter itself is called Intrinsic Motivation. It doesn’t have to come naturally. It can be learned. But that’s a whole different subject.
  2. Pair Programming is covered well in Extreme Programming Explained by Kent Beck.

Now read this

Deployments per Week

One of my Software Development idols, Gojko Adzic, retweeted MindMup’s tweet regarding their high amount of deployments: That’s a whopping 1.06 deploys per work day! So I decided to look into our deployments per week - just to get an... Continue →