When to Name

Programmers often seem to be reluctant to name things. Considering names like PCMCIA, ISDN, and SCSI, perhaps this is a good thing. And some programmers believe that names really don't matter. They say things like "I don't care what you call it, just as long as it works." That's a bad approach. You should make a conscious effort to name an object as soon as you identify it as one requiring a name. Don't let the difficulty in naming be an excuse—pick the best name you can. Choosing a less than perfect name early in the process and using it consistently is far better than trying to choose the perfect name at the last minute. Naming early on at least indicates that the object needs a name and motivates people to think of better names. Avoiding choosing a name doesn't have the same effect.

TIP

---

A good name now is usually better than a perfect name later.

Managers often "help" this situation by stepping in and assuming responsibility for choosing the names. When they do this, they sometimes don't assume the responsibility for choosing the name in a timely manner: "Have we chosen a name for Xanadu Project yet, Bob?" "Not yet, Joe. We've been having a lot of meetings lately. I won't be able to get on it for a while, I'm afraid." And sometimes managers seem to be under the impression that since the names they will eventually choose will be so fantastic, they can delay the decision until a week before the project ships. I once worked on a project where management chose the name after the product shipped. The user interface, documentation, and packaging all had to refer to the name of the data, never the product itself. Not good.

Whenever anyone takes responsibility for naming things, you should make sure they understand that choosing the names in a timely manner is a significant part of that responsibility.

TIP

---

The responsibility for choosing names includes the responsibility for choosing the names in a timely manner.