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.
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:
- The difficulty of the challenges faced fit the competences of the actor: the programmer is challenged, but not excessively so.
- There are clear rules—what is a valid program? does it run?—and goals for the actions of the actor: what should the software do?
- There is autonomy in how the goal is met: the developer chooses the specific abstractions and approaches used.
- There is constant and concrete feedback: progress can be constantly monitored by running the program or running tests.
- The developer is not distracted, and is allowed to concentrate on the task at hand.
- The developer is motivated by the work itself, and not where it leads. They enjoy the process.
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.
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.
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:
- The group must share a frame of reference: they know the same terms, they understand that they are solving a problem together, and they share an understanding of the problem at hand, and the imposed rules. They must be able to communicate quickly and efficiently.
- All members of the group get the same feedback, and they react together.
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: 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).
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.
- 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.
- Pair Programming is covered well in Extreme Programming Explained by Kent Beck.