Communication Is Hard

Communication is the process of conveying information from a sender to a receiver with the use of a medium in which the communicated information is understood the same way by both sender and receiver. (Wikipedia)

I've been reading Domain Driven Design-Quickly recently and reviewing it with some friends, and I've done a lot of reflecting on what value I think the book holds.  What really struck a cord with me was chapter 2, "The Ubiquitous Language". 

In summary, chapter 2 asserts the importance of developing a core language that is shared and understood between the customer and software developers.  In the context of the book, the authors point out the challenges of communicating requirements and success criteria for software development, but I'm taking this idea further and investigating other areas I can improve in my communication. 

For geeks like me, it's easy to talk for hours on methodologies, war stories, the cool latest tech, and so on.  I think it's fair to say that most of the time when we are talking, we assume that our audience is understanding what we're saying, but it's not always the case.  Think about all of the terms we throw out on a daily basis that can carry different meanings depending on context and your audience's experiences.  Here are a few of the usuals that are suspect for ambiguity:

"Service"
"Security"
"Model"
"Design"
"Framework"
"Business Object"
"Layer"
"Tier"
"SOA"
"Repository"
"Factory"

These words are all extremely useful, and convey very important software concepts.  But take a minute to think about how these words could take on different meanings when put into different contexts.  Not only that, but your audience may be thinking something completely different based on their training or experience.  In casual conversation, this carries little to no significance, but if you're explaining how you want a system to be constructed then you're going to be in for some frustration. 

Here are some of the communication touch points I make as a developer, and success indicators.

* The code I write.  Does it communicate clearly my intention and purpose as it relates to my client's business?  Are my classes well defined and have a single clear purpose?

* Interaction with my client.  Does my client understand the solution that I am delivering to him/her?  Am I able to convey my design decisions and where I am spending my time so that they feel as though I am providing as much value as I possibly can?

* Communication with team members.  Am I actively listening and making sure that we are really speaking in the same language?

If I'm not taking an active role in making sure that I'm communicating in a language that both parties understand, then I'm probably going to be misunderstood.  As a developer, I need to put more emphasis on communication.  It's one of the most challenging aspects of my job, and if done poorly can mean failure.