Software development as a communications problem

Something that I’ve been thinking a lot about lately is ‘software as a communications problem’. By which I mean that we have an idea for a software product and, unless we are building it ourselves, we have to find a way to communicate the idea to other people who are going to be responsible for building the software. That is to say that a ‘mental picture’ in your head needs to turn into a ‘mental picture’ in the head of someone else before it is finally translated into something that can be run by a computer. For example:

Founder -> CTO -> Developer -> Computer

Ever played Chinese Whispers?

There is a key difficulty in how I transfer my mental picture into your head so that it looks the same. If I said to you “Draw a house” how likely is it that your picture and my own picture will look the same? What if I draw a 2-up 2-down semi and you’ve drawn a 4 story mansion? And, even if they share a common structure, it is likely that the details: windows, facade, position of doors and so on are going to vary enormously.

This is hardly a new insight and the software industry has been attempting to deal with this problem for many years. The whole agile movement, for example, is about trying to reduce the surface area available for communication problems. But what is concerning me is how insular the discussion in our community is. We don’t seem to be involving linguists, semiotics experts, or anthropologists - people who understand a lot about how people communicate with each other.

The communication problem should definitely be investigated, but I think that the problem is even harder than that: while different team members might be describing the same thing, they are all looking at it from a different angle (or, leaving the metaphor, from a different expertise). So what looks like a human need to one, looks like a business opportunity to the next, like a technical problem to the next, like an implementation issue to the next, like some data that needs to be pushed from A to B to the next.

The problem is not only that I need to understand your mental picture, the problem is that once I have more or less understood your mental picture, it would be very helpful if you were willing to understand my mental picture, which is from a different angle than yours.

1 Like

Yes, you raise a very good point taking it to the next level, also pointing out that it works both ways.

So, even in the simple context in which I was considering the point, while you must first receive the mental-picture and then I have to receive and interpret your mental-picture to know whether my concept arrived “intact”. Then we get into a complicated process of back and forth to try and understand what we both mean.

Further, as you say, there are other perspectives. That we may necessarily interpret those pictures differently and for good reason.

Well, thanks for making my problem harder, now … what we can we do about addressing it? :slight_smile:

So, taking my anthropological study of intercultural interactions as a starting point, I’d say - don’t underestimate the value of actually just alerting people (in a deep way) to the fact that they come from different cultures. After all, most of the people involved in software often nominally come from the same (or presumed similar) national/regional cultures and simply haven’t thought about the ways their functional occupations define their thinking.

I have more to say on this, but I need to sort through the thoughts a bit.

Hi Indy. Welcome to COMPASS :smiley:

This is a good suggestion although the “in a deep way” is the trick. I do try to emphaisze that people come from different places and I think this is enough to create a small change but - when things get difficult - I think people tend to retrench to a more comfortable view-point. How do we make that deeper change?

I look forward to more thoughts from you on this.

Matt