It’s hard to coordinate and communicate effectively

In software projects, it’s hard to coordinate and communicate effectively. This should come as no surprise to anyone developing software for a living, yet it bears repeating because it’s one of the main motivations for adopting the Shared Understanding paradigm that I discussed in my previous post of this series.

The fact that coordination and communication are hard is well established. There seem to be at least three factors that make it difficult:

  1. An abundance of information (and a scarcity of attention)
  2. Lots of tacit knowledge that is very hard to externalize, but that still needs to be communicated somehow
  3. An exploratory or creative aspect to the project (so that there are no clear answers, and probably no clear goals either)

So, too much information to parse, knowledge too complex to make explicit, and questions for which we don’t yet know the answers, or which we don’t yet know exist. Whenever these factors hold (and I argue they hold for a very significant chunk of software projects; certainly for every project I studied), we won’t be able to coordinate and communicate effectively with a simple transfer of information—we’ll need a deeper understanding of the project’s situations, and that understanding needs to be shared by everyone involved in them. In my next post I’ll discuss how (I think) we can reach that state of shared understanding more easily.


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.

3 Responses to It’s hard to coordinate and communicate effectively

  1. Galax says:

    A bridge. In my experience, a person-bridge is part of the answer.

    The software developer can talk to the machine. The user of the software knows his field and (hopefully) his needs. Part of the problem is they do not speak the same language. So, you need someone who knows enough of the object of the program being developed, and who at the same time has a good understanding of what a programmer is capable of delivering.

    Let us say software is being developed for medical purposes. We will need a software developer with a fare understanding of medicine (improbable) or a physician who is not afraid of computers and its workings (better odds) to act as a bridge between the parts.

    • Jorge Aranda says:

      Yes, that’s a start!

      By now we have a whole field studying how to tease out what users need from their computers, to find their “requirements.” But once you find them (or “elicit” them, a better word, since they weren’t hidden in the first place), you need to have everyone else in the team of developers understand what they are, and then they need to coordinate to figure out what to program first, and how will all their pieces of code work together. If you have dozens or hundreds of developers this might be a huge problem. And if you have many users as well (hundreds? thousands? billions?), and they don’t fully agree on what they want, you get an even bigger problem. Though bridges are sometimes essential, and though they almost always mitigate the problem, they don’t make it go away.

  2. Pingback: What makes coordination and communication easier? | Catenary

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 )

Google+ photo

You are commenting using your Google+ 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