Three paradigms on software development

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:

Photo by Ed BurtynskyFirst, 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.

Enron emails networkSecond, 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.

Blind men and the elephantMental model of the elephant

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.


About Jorge Aranda

I'm currently a Postdoctoral Fellow at the SEGAL and CHISEL labs in the Department of Computer Science of the University of Victoria.
This entry was posted in Academia, Software development. Bookmark the permalink.

6 Responses to Three paradigms on software development

  1. Neil says:

    Where would you put kanban boards in these headings? They clearly improve coordination and communication. They definitely fit in the process view, but also in shared understanding.

    • Jorge Aranda says:

      Well, to clarify: it’s not that a tool or practice falls in one heading and not the others, but that you can analyze the same tool or practice from several perspectives, leading to different insights. So you can study kanban boards as part of a process, you can study the ways in which they change the flow of information in the organization, and you can study the ways in which they help the team share a better and deeper understanding of their situation. The concluding recommendations might be different for each analysis, of course, but we can try and evaluate their usefulness empirically.

  2. Pingback: It’s hard to coordinate and communicate effectively | Catenary

  3. Pingback: Naur’s “Programming as Theory Building” | Catenary

  4. miki says:

    good stuff man
    am doing my undergraduate I find your article timely down here in Kenya.

  5. peter says:

    i will love to have a detailed understanding of software development and project management analysis

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s