Component-Naming Rigor (CNR)

Whenever software engineers are asked to list the most difficult aspects of their jobs, the problem of coming up with good names for their components is always somewhere near the top of the list. Naming components is difficult for the same reasons that naming products is difficult. When you try to find a good name for a product, it can be a significant struggle to find one that is unique within the industry, memorable to the consumers, and yet still meaningful to everyone. Software engineers face the same predicament when naming their software components, but they go through it multiple times a week rather than just once a year. When they create a new class, type, data-structure, or module, they need to give it a name that is unique, memorable, and meaningful. If they fail to do so, they will not only confuse other developers, but they will even confuse themselves.

Good names are especially important for shared components that are used throughout many different projects. Shared components are mentioned often in conversation, meetings, and even documentation, so giving them names that everyone will recognize and understand is important. On the other hand, clients will never care, or even know, what the source-code components are called. The application will perform exactly the same regardless of how well the components are named. It's purely an internal issue which only affects maintainability and cross-training. It's important to take the time to name things appropriately, but it's bad to waste too much time on something that is inconsequential to the quality of the end product.

If your engineers are stuck trying to find a good name for something, you may want to recommend that they consider using a TLA. TLAs are magical things that have all of the qualities of good names without any of the agony. So what is a TLA? The term TLA is a three-letter acronym which stands for Three-Letter Acronym. You'd think that TLAs would be difficult to remember, but it's amazing how well your brain can recognize them. You might think that you are only able to immediately understand TLAs like API, IDE, HDD, RAM, and PDF because they are all being used in the context of software development, but I bet that my American audience will have no trouble recognizing random TLAs, like IRS, LAX, NBA, KJV, and GOP, even when they are used completely out of context.

Why does it have to be three letters? Well, it doesn't have to be, but there is something magical about TLAs. They are just long enough to be distinctive while still being short enough to be memorable. ETLAs can work well too, especially when three of the four letters forms a pronounceable syllable, like JPEG (i.e. “jay-peg”), but, otherwise, TLAs are preferable.

Obviously, too many TLAs can become unwieldy, but judicious and appropriate use of them can be very beneficial. So, next time your engineers are struggling to invent a name for some common component, like a Hashing File-source Metadata Comparer, maybe they should just call it a Hashing FMC.