Communication is key, and software development is no exception. Anyone who has worked with developers knows how tricky communication can be, whether they are talking about bugs, new features or even layout. While effective language may be a headache for project managers who rely on effective communication, it surprisingly might be just as big of a problem for developers. Martin Fowler, one of the most acclaimed experts on software design, famously said “naming things” was one of the hardest problems in programming. He’s not wrong. Most of a developer’s time is spent reading, understanding and fixing code— not writing it. To a developer, readability and word choice is everything.
Describing and specifying large projects is an art in and of itself— but often it feels like different team members are speaking an entirely different language, or, even worse, making up a language as they go. I can’t tell you how many times people have described some part of a website as “that thing” or “the guy that...”, only to follow it with a list of descriptors in hopes I can narrow it down. Often times I can, but sometimes I can’t— and that means one more email, phone call or meeting before I, as a developer, can start working.
Quite frankly, if you don’t share the same nouns and verbs and an understanding of what they mean, you really aren’t speaking the same language at all.
Fortunately, there are strategies to help deal with this. A technique called “ubiquitous language” emerged in the 1990s in a system of strategies called Domain-Driven Design made to help organize and solve complex problems within large enterprise software.
It’s a simple concept— come up with words to describe your system, the best ones you can, and use them universally and ubiquitously. One name per one thing. Now you’ll have everyone on your team, quite literally, speaking the same language. Ideally, these language choices are well documented and shared between everyone in the project.
Of course, some word-choices are better than others and ideally you want an expert to come up with the names. If your developer is writing software for making sheet music and they don’t know anything about composing music, it could be worth taking the time to educate them, rather than letting them make up new names, when everyone would prefer to use the correct name. These experts are familiar with end-users or the target industry. So, instead of developers calling it a “five-lined-note-thing” they can correctly refer to a musical staff.
While it can be hard (albeit worthwhile) to sell this process to your entire team, one practice I do, that you can start doing today, is spending the time to come up with basic terminology, and sticking to it. I prefer to use the words others are already using since for the most part, I know they’re going to be understood. I use these words consistently in my code and when speaking to clients. Fortunately, good concise language choices can be infectious.
However, just using the words isn’t always enough. If you have requirements, it is of utmost importance that there are documents of your ubiquitous language. In fact, starting a glossary documenting this language as part of your software specification can insure that everyone is on the same page. And, if the language and terminology were to change, everyone should be made aware of the changes.
Sharing a common language between users, developers and the rest of the team reduces the chance of miscommunication, helps developers produce better code that is easy to understand and helps facilitate effective communication about business logic, user experience and layout. Without it, programmers may often resort to using technical jargon. And, although end-users and experts may define the ubiquitous language, sometimes programmers attempting to formalize it, make it rigorous. In the end it’s a team effort that will lead to effective communication, saving you time, money and frustration.