While
at lunch with a buddy of mine the other day he shared that he came to a
startling revelation. He was listening to a presentation on Services Oriented Architecture (SOA) the day before and
realized that much of his job was terms definition. Simple things like, what
does the word “Enable” mean to you. What is an Enterprise Network
Bus?

In software development we often use terms with one another
which are poorly defined and have different meanings to different members of
the team. We assume that when we say “factory pattern” the person on
the other end understands us the same way they understand us when we say
“cat.”  This is, however,
rarely the case.

In
this article, we’ll explore the need for a common lexicon (see the dictionary.com
definition for details) for your software development team and look at what you
need to do to create it.

The Tower of Babel

“The LORD said, ‘If as one
people speaking the same language they have begun to do this, then nothing they
plan to do will be impossible for them. Come, let us go down and confuse their
language so they will not understand each other.'”
The Holy Bible, New International
Version, Genesis Chapter 11, verses 5-7

When
people speak with one language, one understanding of each other, they are able
to accomplish almost anything. The more that we are able to speak, hear, and
understand each other the less time is wasted on stupid mistakes and
misunderstandings.

Most
people have had situations where we’ve given direction to someone and come back
only to find that the direction we gave wasn’t clear to the recipient. Or at
the very least we’ve taken some direction from someone and when we demonstrated
what we had done they indicated they were expecting something different. (This
still happens when my wife asks me to do something.)

It’s
annoying but in software development it’s costly. Estimates vary but the
general consensus is that over 40 percent of a project’s budget may be consumed
by rework. If you consider that most of this rework isn’t because of poor
understanding of how the technology works, but in because of poor
communication, you can see a great potential for improvement in the performance
of your team by communicating better and reducing rework.

The
foundation for creating less rework is in developing a common language that you
can use to communicate as clearly as possible. It will never be perfect, but
having the same understanding of a word will radically improve your chances of
fully understanding what someone else is communicating.

Relearning existing vocabulary

One of
the challenges with meeting the call to develop your own lexicon, your own
language, with your developers is building common experience and common
understanding of the things that you already believe that you know. You may
believe that you know what the other person means but in reality you probably
believe something slightly different.

Take
for instance, when I said “cat” above. You may have thought I was
talking about “Fluffy” the white haired Persian cat that you had as a
child. Or perhaps you were thinking of the Calico cat you have today. I was,
however, actually, referring to one of the Bengal tigers that I recently saw. Should
I have pointed out that I was speaking of a “big cat”? Probably, and
if I was giving direction I would have. However, even big cat isn’t specific. Would
I be referring to a leopard, a lion, or a tiger?

The
point of all of this is that we all share a vocabulary but we each define the
words slightly differently. The trick is to pull the definitions of a group of
people together as much as possible so that you can use words and know what
they will mean to your team members.

One
technique for doing this is finding examples of articles, white papers, etc.
that defines the term and expands upon it’s meaning. For instance, Services
Oriented Architecture is a difficult thing for most people to define. However,
you can bring folks to a common understanding by asking or encouraging them to
read the same article on SOA as the rest of the team. While everyone may not
agree on every specific point about SOA raised in the article it creates a
reference point that can be used to anchor a definition that everyone on the
team agrees upon.

That
anchored definition allows you to define other terms in relationship to it, and
to other terms, and helps to strengthen the continuity of understanding between
team members. However, even well understood, anchored terms may not be enough.

Creating new vocabulary

Your
existing vocabulary is a good start. With seasoned practitioners there’s a wide
variety of words and phrases that have – or can have – a specific meaning. However,
there are times when the existing vocabulary just won’t cut it. When you’re
trying to describe your own techniques, processes, or methodologies, you may
find that the existing vocabulary just doesn’t cover it.

A
former coworker of mine, David Feinberg, has a dream. He wants to get a new
word added to the dictionary. It’s a great dream, and I wish him luck. Of
course, whether he does or doesn’t succeed in his goals, he’s good at
introducing new words into his organization. The beauty of these words is that
they mean a specific thing to everyone in the organization – and there is
little chance of anyone outside the organization having a different definition.

Although
it may seem like having others not know the word would not be a good thing – it
can be. It’s good because there’s a low chance that the word will be
misinterpreted. Because there are no other context clues as to the meaning of
the word, it’s likely that the only definition that the team will develop is
the one that is intended.

The
most difficult problems to troubleshoot, diagnose, and fix are those which are
not clear and repeatable. The same goes with communications. If you can’t see
that it’s a problem, and if it’s not a problem all the time, you will probably
have a hard time getting people on the same page. A new vocabulary item has the
benefit of being understood or not understood, but with a very low probability
of being understood incorrectly.

Culture of precision

One of
the great benefits that I get out of having different professional editors
looking at more than 80 percent of everything that I write is that they have
encouraged me to be more specific in my writing. I can’t just say things happen
– I have to be more specific about what, when, for how long, etc. We all speak
in somewhat general terms when we are speaking. It’s less formal and we’re
thinking on our feet, however, the general way that we approach speaking leads
to a certain amount of ambiguity and imprecision. The most frequent situation
that illuminates the lack of precision is when we ask someone a question via
email. We indicate the question but rarely
do we actually indicate a deadline for the response. We leave ambiguity in how
long the person has to respond to our inquiry.

The
impact of a culture of precision in speaking and writing is subtle. It is
subtle because you can develop your own lexicon for developers without it;
however, it’s like a catalyst. It can accelerate the process. By making the
team hunger for precision in their communications they will seek out the most
precise words they can find to express their ideas. Instead of just being
satisfied with the idea that a data entry screen is necessary, they’ll begin to
explore which of the standard operations they need. Instead of data entry
screens you’ll get something like. “We need an edit screen for the
customer list capable of adding, reading, editing, and disabling a customer. We
never delete customers so that isn’t necessary.”

Perhaps
it takes a few more words to communicate like this, perhaps even a minute’s
worth of time is “wasted” by this precise way of communicating, but
that certainly takes less time than coding a delete feature into a screen that
will never be used because the business process doesn’t allow customers to be
deleted.

Culture of refinement

A
culture of precision is not only about speaking and writing in precise terms
but is also about learning how to hear with precision. In other words,
communicating in precise terms also requires that the listener verify the
meaning that they attribute to the words that the speaker used. A culture of
refinement is one where listeners are encouraged to challenge their
understanding of what the speaker said by echoing back the understanding – and
not the words. This leads to an automatic refinement of the message which makes
it even more precise.

The Humanist
approach to psychology
is based upon the idea that you tell the person what
you just heard. The technique is both validating to the patient and
illuminating to the counselor. The patient feels like they’re being truly heard
and has an opportunity to expand upon the details of the situation or how they
feel. The counselor verifies their understanding of the patient and in return
understands better.

The
basic format is the speaker saying something like “I believe we need a
SOA-based approach to this problem.” The recipient (or one of the
recipients in a group setting) says something like “I understand that you
believe Web services are the right way to go with this project.” The
response doesn’t use the same words that the speaker used. It uses a slightly
different construction and in this case with a slightly different meaning. The
result should be the speaker responding with “Yes, but I believe we need
to address queuing and the transactional nature of what we’re doing. I also
believe that we have to focus on maintaining loose coupling.” This
interchange has illuminated that the speaker believes that queuing
(asynchronous operation), transactional processing, and loose coupling are
important components of the solution. Without this reflection of meaning back
to the speaker this information would have never been shared.

This
culture of refinement, where everyone is trying to refine their understanding
of what is being said can be a bit overwhelming at first as it initially
increases communications, however, it has the potential to substantially reduce
rework.

The world at large

One of
the challenges that occur when you create your own lexicon for communication is
that the world creeps in around you. You’re overwhelmed by messages from the
rest of the world which may have a different definition of your terms than the
group defines. That’s one of the reasons why it’s important to find your own
vocabulary so that you don’t have to battle a different meaning in the world at
large. Prefixing terms with ‘OurCo’ such as in OurCo-SOA can help to keep the distinction even when the
world has a slightly different or less refined meaning.

Ultimately
there is one major caution with your lexicon. That is not to make it conflict
with the meaning of the world at large. So you wouldn’t, for instance, want to
define a Web service as a Web site that users use on top of existing mainframe
applications. The definition would be substantially inconsistent with the
definition used by the rest of the world and would simply lead to problems of
misunderstandings when you try to bring in new people, communicate with your
peers, or even get consultants “up to speed” as they come in.

The
best way to view your lexicon is a dialect. Something that resembles the way
the outside world communicates, but has special and unique meaning to the team
– a meaning that makes it easier and more productive to communicate.

The mind

You
may not need to create a whole new language or learn some obscure language like
Klingon but you should consider how you communicate
with your team and how you can create your own lexicon for communicating back
and forth with one another.

Learn
to anchor your key terms and apply your own definitions to new words to form a
stronger bond between the meaning behind the communication in the mind of the
speaker and the meaning behind the communication in the mind of the listener.