“See, there’s always a duck,” I said to my colleague. I’m from the US; he’s from Finland; and we were both in Portugal on business. We’d taken a break from work to take a walking tour in the mild weather. I’d already told him how my youngest daughter had had declared the ubiquitousness of water fowl. As we were walking, I spotted a duck. I thought he would appreciate the joke.

“That’s not a duck,” he replied.

“Yes it is,” I said.

“No, it’s not,” he replied.

It occurred to me that maybe ducks in Finland look different. “OK,” I said. “If that’s not a duck, what does a duck look like?”

“White,” he said. “And bigger. That’s not a duck, it’s a sorsa,” he gave me the Finnish name.

Certainly, the duck we were looking at was not white. It had the colorful markings of a male mallard. “Right,” I said. “There are white ducks and colored ducks. But they’re both ducks. A sorsa is a kind of duck, right?”

“No,” he insisted. “Ducks are white and have bigger beaks than this.”

I began to sense that we might be talking about two entirely different things. “Big white water bird,” I mused. “with a bigger beak. Do you mean a goose?”

As we sorted out the difference between ducks and geese and sorsa, it dawned on me that this English-Finnish discussion offered a good example of the difficulty in sorting out a common language on software projects.

I started remembering all the conversations in which someone used an overloaded term like “server.” Or “test.” Or “done.”

For the record, it turns out that we were, indeed, looking at a sorsa. And it was, indeed, what I would call a Mallard duck in English.

But just contemplating how much effort it took to establish this simple basis of understanding about something we could see and hear, I am astonished that business stakeholders and technologists on software projects – something truly intangible – are ever able to achieve any kind of shared understanding about what we’re building and how it should function.