Language Matters

June 19, 2009 — Posted by Scott Bain

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 tweets.

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. Glass Half X

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-

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Scott Bain

Scott Bain is an consultant, trainer, and author who specializes in Test-Driven Development, Design Patterns, and Emergent Design.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban