In my previous post on this series, I argued that the activity of software development is unique, and that we tend to use metaphors to make sense of some of its aspects. Often, however, the metaphors we use run deeper and are more subtle than a simple reference to, say, bazaars or surgical teams. Depth and subtlety make our metaphors more powerful: we may not realize we are using them, but their assumptions and values inform the way we see the world. My favourite example comes from a study about boardgaming behaviour: people who are asked to play “the Wall Street Game” are far more ruthless and agressive than those asked to play “the Community Game”, even though both games have actually the exact same rules (an implementation of a Prisoner’s Dilemma).
So, reading the literature on coordination and communication in software development, it seemed to me that there are three particularly important metaphors, or paradigms, that people use implicitly to make sense of the field:
First, there’s the perception that software development is a kind of manufacturing process, and that in order to improve upon it we need to design software development processes and methods that produce repeatable, controllable, and optimizable results. I call this the “Process Engineering” approach to software development. It usually implies a documentation- and measurement-heavy approach, as it’s difficult to achieve repeatability without clearly defined and easily evaluated processes.
Second, there’s the idea that information is some (ethereal) substance that flows among people and between people and things. This idea is quite widespread in our everyday language: we “put our thoughts in paper,” for instance, or we “get our ideas across” to someone else. Subscribing to this paradigm, which I call “Information Flow,” implies trying to design social structures that allow for knowledge to reach most easily those places where it’s needed the most.
Finally, there’s an alternative approach for which communicating and coordinating is more complex and more difficult than the simple transfer of information. We misunderstand what each other is trying to say and do all the time, and getting to a robust agreement on any non-trivial situations is a challenging task. According to this perspective, which I named “Shared Understanding,” the goal is to find and refine strategies to help software teams achieve a robust understanding of their situations as efficiently as possible, knowing that communication breakdowns are bound to happen and that total agreement is never certain.
What I found most interesting is that the strategies one proposes to improve coordination and communication are essentially tinged by the paradigm one subscribes to:
- If I take a Process Engineering perspective, then I will probably propose that organizations should adhere and comply to some prescribed processes, and that they should emphasize communication through documents and through formalized interactions.
- If I take an Information Flow perspective, I may focus on analyzing and improving the socio-technical system of a software organization, pointing out the structural problems in its social network. I will also probably base my analysis on mining data from electronic repositories, such as bug databases or email records, that will allow me to get an approximation of the social network I’m studying.
- If I take a Shared Understanding perspective, then I might try and help members of a software organization to negotiate and come to a better (and shared) understanding about their goals, plans, status, and context. I will focus on their interaction dynamics and on those cases where, even though there might have been a flow of information, communication actually failed. Once I understand why those breakdowns occurred, I might have a better idea about how to minimize them or their impact in the future.
I think all of these paradigms have their merits. The first one has always been present in our field, and its limitations are by now fairly well known. The second is increasingly popular among researchers, and lately it has been giving us plenty of interesting findings. The third, which is the one that interests me the most (as I think it makes the best fit with my observations), seems to have been on the sidelines of mainstream software research for a long time, always sort-of present and producing interesting findings, but not taking a strong foothold in the field.
As a community, however, we haven’t really articulated these perspectives, and I think this causes some confusion, as groups of researchers talk past each other: you talk about processes when all I see is communication breakdowns, for example. To try and help fix this problem, what I did for my thesis was to take the last of them, the “shared understanding” perspective, and flesh it out. The result was a theory of coordination and communication in software development built upon this paradigm, and (I think!) it gives us several useful insights about how to improve the practice of software development. In the next posts I will briefly explain the theory and its implications.