Last year I was diagnosed with a "nodule" on the right side of my thyroid (this is the word they use when you have a tumor and they don't want to freak you out). My doctor told me that the nature of the thing (soft, large) meant that it was unlikely to be cancerous, but that we might want to remove it anyway because it might turn cancerous later.

I asked "would I have to stay overnight in the hospital, or could this be done on an outpatient basis?"

He nodded and said "well, it's superficial, so…"

I interrupted. "Ah, good, so it's no big deal."

He looked puzzled. "Um, no. What?"

"You said it was superficial, so that means it's no big deal, it's trivial."

"No," he said, "it is not trivial, it is superficial."

He reminded me that "superficial" means "near the surface". A superficial iceberg is anything but trivial to the ocean liner. He was telling me that my nodule was near the surface, where there are lots and lots of blood vessels, and therefore they would have to keep me overnight to ensure that I had no bleeding problems after the surgery (I didn't, and it was benign, and I'm fine).

I submit that the average person has "superficial=trivial" in their head today, and so the word has lost much of its useful meaning. That's too bad. Two words that mean the same thing are not as valuable as two words that mean two different things.

Technology can make this worse. The letters my mother wrote me when I was in college were painstakingly crafted with perfect penmanship and great attention to detail. Most emails I get are simply awful in terms of language, construction, clarity, and meaning. Forget tweats.

As software developers we are members of a very young, maturing profession, and we have the opportunity to avoid this problem if we are careful with the words we use, and if we strive to keep their meaning distinct.

This is also an issue of context, of course. Is the glass half full, or half empty? The traditional view is that it's half full if you're an optimist, whereas it is half empty if you're a pessimist. I say that the glass is half full if you're filling it and it is half empty if you're emptying it.

And if you're doing TDD, you have twice the glass you need for the requirement. Reduce the size of the glass. J

Developers are often confused by the patterns when they first encounter them, because many of them appear to be the same. The Adapter, Façade, and Proxy patterns all appear to have the same architectural role, essentially a "go-between". The fact that many people call them all "wrappers" speaks to this problem… they are not all the same thing, so we should not use the same word to describe them.

Similarly, the Decorator and Chain of Responsibility patterns appear to be essentially the same because their structures are so similar. They are in no way the same thing, but if we call them both "pipelines" (which I've heard people do) then we discard their true meaning and we rob ourselves of valuable communication tools.

We also have words for the qualities that the patterns help us to improve in our code. Strong cohesion, intentional coupling, and avoiding redundancy are examples of this. We want these words to be specific, however, and we must remember that their meaning, for us, is not always the same as it is for those who are not in our profession (and who frequently supply us with requirements)

The word "redundant", for instance, to non-technical people generally means "un-needed", to an engineer means "we have a backup", and to a software developer means "we have a serious maintenance problem" (like Y2K). We have to take these differences into account, and remember who the audience of our communication is at any point in time.

I'd love to start a conversation about this.

-Scott Bain-

Technorati Tags: Coaching Design Patterns Testing

tag with del.icio.us