Making Software

A Communal Workshop

Here is the problem with our previous discussion: in the DeMarco and Lister study, people work on a task individually. They code and test individually, and they will be ranked individually. All that matters is how much they can concentrate, on their own, on solving their problem in the best way possible.

But in most cases software isn’t developed like that. People are not fighting a lone problem on their own: they are part of a team. The product of their individual work has to interact with that of many others. They get help, they provide help, they’re in it together. Therefore, everyone on the team needs to coordinate and communicate with their peers, constantly, throughout the project.

These coordination and communication demands can be quite intense. As Brooks pointed out in that other classic text on software development, The Mythical Man-Month [Brooks 1975], they can be so intense that adding people to a late project can delay it further due to the resulting coordination overhead.

Thinking about coordination forces us to consider an alternative to our “doors that close” prescription. Perhaps what matters is to have an environment where people can coordinate and communicate constantly and swiftly. Perhaps an emphasis on coordination beats an emphasis on concentration.

It turns out that there are many theoretical reasons to emphasize coordination. First, we should remember that nowhere in Csikszentmihalyi’s theory of flow does he say that flow happens exclusively ...