How often do you really think of a good name before you start writing code? From my experience I never do this, I just come up with names along the way which complicates some things:
- You need a name for your repository
- You need names for certain classes
- You need a name to be used in documentation
If you don’t think of a name up front, you will likely have used a very technical name which down the road may not fit the application anymore. Maybe you just got tired of the name, or you initially said that it was only a temporary name. But replacing an existing name can be very painful.
So which three strategies for naming do we have?
- Think of a good name upfront.
- Use a temporary name.
- Have a separate public and internal name.
Probably the hardest thing to do is to think of a good name upfront, as it requires input from Sales and Marketing to get their approval. By no means this name can be too technical, it should just be something catchy and maybe something with a story behind it. The biggest problem with this approach is that you block all your work until you have found a name. It becomes even worse when the application outgrows the name after a couple of years, or if it is decided that the name needs to be changed nevertheless.
It is easier to use a temporary name, such that work can just be started and when you are ready to release the application you can think of the right name for it. At this point you know what the application does, and you had some more time to think about a name. Nevertheless it is, just like thinking the name upfront not future proof. Moreover it is possible that before the release a lot of documents need to be changed for this new name. In the end it is very likely to have a lot of documents using the old names, and some other documents using the new name. As long as only the new name can be seen by the customer this is acceptable, yet internal confusion should be avoided at all cost.
The final approach is just to have multiple names for the application. During development you can use a non-attractive internal name and when you are getting ready to release you change user documents and interfaces to use the public name. While this takes less effort than using a temporary name, it is guaranteed to confuse certain people internally as both names are there to stay. Whenever the public name should change, it is often only required to change it in a couple of places which can easily be managed.
In my opinion all of these approaches fail at some part: the code. While writing code you need to have names for your classes, packages, methods, fields and many other things. It is strongly advised to use a generic concept rather than a term you invented, it is however unavoidable to have terms seep into your code or the other way around. After all they are essential to be able to communicate with other people about it. If these terms are connected to public names, they either have to change along with them, or they are left behind. Whatever is chosen to do with these names will be the approach from above. In code it is critical to have names that tell you what it means and does, this eliminates the possibility of a clean public name, except for the higher and more general concepts.
Do not take your names lightly as they can cause you much burden later on. If you are not fond of thinking of smooth names at least use some technical clear names to avoid internal confusion.