According to Phil Karlton there are only two hard things in computer science: Cache invalidation and naming things. We’re currently experiencing how important the latter one is. Finding the right name for something and then sticking to that name.

At BetterDoc we’re currently digging through a lot of technical stuff that has been created within the last couple of years trying to align all of it to what the people working with our software actually need today.

As with a lot of software projects the reality (how people use our software) has diverged enormously from the original ideas and intentions. An important part to find out what we really need is to have a common language so that everyone knows what we’re talking about.

Let’s take an example: In the past our internal application that is currently used by our patient care team and our medical research team didn’t have a name. So when talking about features or defects people didn’t really know how to call it.

That’s when creativity and resourcefulness arrived on stage.

The frontend part of the application is written using Ember.js and on the initial screen a message “Ember is loading..” is displayed whenever the application is loaded. Voila, everyone could see that message so it was only natural to assume that “if Ember is loading than that thing must be named Ember”.

So, here we are: A few years have passed and everyone simply calls the application Ember.

But where is the problem with that?

In the reality of software development the term Ember has a clear meaning: The JavaScript frontend framework. In the reality of our BetterDoc software landscape Ember is just one component of the overall application: the frontend part (it get’s even more complicated as it’s not the frontend part but one frontend part).

In the meantime when talking with or within the development team the term Ember has become totally ambiguous. When someone refers to Ember does 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’s a nightmare.

Having experienced this has made us realize that every new service that we will provide needs a clear name that signalizes to everyone what the service does instead of the technology that it uses.

It may seem superfluous to spend 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 by not having to ask for clarification over and over again and by not having to realize far too late that you headed into the wrong direction because you assumed the problem was in a completely different area.


Be careful when releasing a piece of software. Make sure that you have a clear name for it and that everyone is using that name consistently.