Naming things
According to Phil Karlton1 there are only two hard things in computer science: Cache invalidation and naming things. I have experienced on multiple occasions how important the latter one is: Finding the right name for something and (perhaps evenly important) sticking to that name.
An important part in finding out what is really needed when developing an application is to have a common language so everyone knows what is being talked about.
Let’s take an example: When starting at a company a couple of years ago I was digging through a lot of technical stuff which had been created over years trying to align all of it to what the people working with the software actually needed.
As with a lot of software projects the reality (how people used the software) had diverged enormously from the original ideas and intentions. The internal application, that was used throughout the company however had never been given a name, so when talking about defects (or new features) people didn’t really know how to call it.
That’s when creativity and resourcefulness arrived on stage.
The frontend part of the application was (and as far as I know still is) written using Ember.js and on the initial screen a message “Ember is loading…” was displayed whenever the application was loaded. It was the default message added by a fresh Ember.js setup and nobody changed it. For the users however it was pretty clear. Everyone could see the message, so it was only natural to assume that “if Ember is loading than that thing must be named Ember”.
Several years later and the application was simply known as Ember to everyone - including the development team.
But why is that a problem?
In the reality of software development the term Ember has a clear meaning: The JavaScript frontend framework. But in the reality of that particular software landscape Ember was just one component amongst many: The frontend component (it got even more complicated as it wasn’t the only frontend component).
In the meantime when talking with or within the development team the term Ember had become totally ambiguous. When someone referred to Ember did he refer to the frontend part of our application being written in Ember.js? The frontend as a whole? The larger application? The JavaScript framework itself?
It was a nightmare.
Having experienced this has made us as development team realize that every new service that we provided would need a clear name that signalizes to everyone what the service did instead of the technology in which it was implemented or that it used.
It may seem superfluous to spend a significant amount of time to come up with a name for a service, an application, a component or a module - but in the long run that initial investment in finding the right name will more than pay off. You won’t have to ask for clarification over and over again and you won’t have to realize - far too late - that you headed into the wrong direction because you assumed the problem was in a completely different area.
tl;dr
Be careful when releasing a piece of software. Make sure that you have a clear name for it and that everyone uses that name consistently.