Naming is hard

I’ve been working on a software project recently, and I got to the point which every software developer dreads: naming. Although naming isn’t the most important feature of a piece of software, it’s good to come up with a name that at least works pretty well. This particular Dilbert cartoon comes to mind:

As Jeff Atwood noted on Episode #37 of the Stack Overflow podcast:

Naming is super hard; whether you’re naming code, you’re naming human beings, naming is just really difficult.

And he’s right. Finding the “right” name or a name that works for software is really hard. When I started to think about naming (which I had deferred for as long as possible) I looked for a few tips on what makes a good name – of course I have some ideas of my own, but I wanted to see what others had to say on the topic. Although quick Googling yields a fair few results I wasn’t too happy with the results I saw, most of which seem to resemble something similar to SEO patter.

So I started thinking: what makes a good name for software, and how do you go about finding it? My first thought was to go for a bit of brainstorming – ideally, I would have scribbled my thoughts on a wall covered in IdeaPaint but at $200 per 50 sq. ft. I decided to go for the old-skool whiteboard. I think that brainstorming is perhaps one of the greatest ways to come up with an idea – even if most of the diagram amounts to no immediate result, it’s a great way to get your ideas down. Then you decide to take a break and come back later, your ideas will still be there, and you’d be able to add any fresh ones.

But what do you brainstorm? I started to think about different perspectives that would affect the name – namely:

1. Who are your users? Since the name is a way of your software sounding attractive to your users, who are they? What background are they likely to have? What are they likely to be familiar with?
2. What is the context? Where is your software going to be used? This often affects the name – since I am working on some software targeted at the Mac, there are certain “conventions” (in a loose sense) or “trends” which affect what a good name for that audience is. I had a look around at similar pieces of software and started thinking about what was common about them; were there certain aspects or a “style” of the name that were part of this context?
3. What does your software do? Often great names can arise from a fundamental word or set of words that explain what the software does. For example, one of the Apple Design Award 2009 winners is an app called Things which is task management software. Part of the effectiveness of this title goes down to the fact that it explains (or at least gives an idea of) what it does in one word. Don’t be afraid to get out your thesaurus for this bit – I found it pretty useful in expanding my ideas by finding synonyms of these fundamental words or ideas.

After I’d got my ideas down I found that I could think about them, and see which bits fitted well together – was it certain words, or ideas that stood out and formed a great name? However I also had periods where I’d have no idea where to go next, and left it at that and went and did something else. Then, when I came back to it I had several new ideas which I could use to expand upon, and since I’d written my ideas down I could continue from where I’d left off.

But what makes a great name? I started to think about this too, and there are perhaps two key points that I decided:

1. Keep it short. Although having a name which explains (to some degree) what it does, don’t be verbose about it (not naming any names, but several Microsoft product names don’t exactly fit this criteria).
2. Make it easy to remember. This often comes with keeping it short, but make sure that it is something that is easy to remember and spell. Often something easy to remember is something original and different, but make sure that it isn’t too obscure.
3. Make sure it isn’t taken. Do a quick search for the name and make sure that your name hasn’t already been taken. If it has is there some way you can modify the name to make it something you like but different from this name?
4. Make sure it isn’t offensive. Particularly if your software is targeted at other languages apart from your native one, make sure that what you choose isn’t something offensive or a turnoff in those languages.

Another point that I started exploring was metaphors; is there something in real life that is a metaphor for the core functionality of the software? If this can be drawn into the name it makes it more effective and easier for your users to remember and associate with.

An important point is that when coming up with the ideas, don’t be afraid to try things out. Write it down, see how it looks on paper; say it out loud, or ask colleagues what they think of the name. Having a list of names that you’ve come up with – perhaps added to the brainstorm, perhaps separate – even if they don’t work, can help to provide inspiration for other names. And great names don’t come quickly – I spent about a week or so thinking about it and coming up with ideas before I found a name that I thought worked pretty well. Don’t rush the process – and when you think you’re sure about a name, think about it some more; make sure it’s something you definitely like and you want to go ahead with.

Although these were my experiences with this, I’ve provided a bit of a generalisation – some projects require more of certain parts and less of others, but these are some things to think about. And naming isn’t the only thing to consider about your software – it’s pretty much a marketing feature. Create a great software product and make sure the name is something that at least works, and things should start to fall into place.