It’s Just Naming Things

Working with a client some years ago, after a few weeks I finally managed to get the VP of Product into a session with software developers to learn from his business mental model. The time was beyond ripe for this discussion, but the situation wasn’t helped when the chief architect uttered the words of this talk’s title: “Why are we wasting time on this. It’s just naming things.”

As it turned out, it wasn’t at all “just naming things.” The VP exclaimed that he’d always hated the terminology used in the software because it didn’t properly reflect what the product actually does; not even close. So he endured the pain for years because the software developers were “just naming things.” This VP endured even though he knew that investors and users alike didn’t understand the software, which required extra sales effort to get potential consumers over the hump and train them after a deal was finally inked.

It’s said that naming things is hard. Actually, naming things is sort of hard. The hardest part about naming is communicating the concept being named in a way that makes sense to listeners and readers. In fact, it’s not just naming at all. Communicating accurately with comprehensive language is about far more than names, which makes effective communication hard. It’s the really, really hard part of software development, as has been proven time and again throughout the past decades.

This keynote digs into why communication is hard and why software project/product efforts fail often due to inferior communication and striving for ordinary outcomes. It uncovers the keys to effective communication and provides great incentive for achieving it. You probably don’t understand how fundamentally messed up our communication is. But you will learn why, and grasp how you can improve your software outcomes when you make efforts to communicate comprehensively and refuse to settle for the ordinary.