Naming Software Artifacts

October 2022 (published October 2024).

The book of Genesis begins with God creating the world by naming its components, and many other creation myths also equate creating a thing with giving it a name.

When creating software, we name things: we name references to values, and the functions that operate on those references. We collect those functions into classes and packages we name, and then we collect those collections and give name to those collections of collections, and repeat that again and again until we run out of abstractions.

Whole programs are named with the intent of hinting at their purpose. Kafka, which I make my living from participating in its development, is a good example of such, when Jay Kreps hoped to bestow some of the famous author's prolific qualities on the software he named after him.

But we often discount the importance of finding fittng names: even if an old joke is that naming things is the hardest task in computer science, I am not familiar with many texts for programmers that contain thorough discussion of naming. The only example on top of my head is the first chapter of Zach Tellman's Elements of Clojure.

Another issue is that once a thing is named, it is quite hard to get it renamed. Too often I find myself having to explain to colleagues something that is only made confusing because of its ill-fitting name. But renaming it would cause even more confusion.

Here I can use the Latinized spelling of my own name as an example: a clerical error made many years ago had it transcribed as “Shay”, instead of “Shy” or “Shai”, which better match the correct pronounciation. But when I inquired about changing the spelling in various records, I found it would be a garganutan effort involving legal proceedings in at least two countries, and thus didn't bother.

This website is hosted on GitHub pages, which collects some data about visitors.