Legacy Naming Conventions Are Holding Us Back
benjaminlabaschin.comNames are hard. When you have 10 of something you can reconcile the ontological needs (e.g. unique id for unique concept or entity) and ‘understandable’ names.
Wikipedia URLs hover on the edge of what is possible but look close and you see temporal stability is poor and often the ontological properties are wrong. (E.g. you can’t say that a Boeing 777 has a certain weight or length because there are various variants of it that don’t have individual Wikipedia pages, same is true for fighter jets, car models, etc.)
When you have a million entities you are often better off using randomly generate UUID’s. People won’t know what they mean but at least sound reasoning would be possible over the domain.
So you're suggesting that instead of names, we refer to UUID's when talking about a service?
It all depends on how many different entities you are talking about. If N gets high enough, "meaningful names" will break down.
At my current job, we have services like "watcher" which watches some data and alerts someone about issues. Should we have called it "alerter"? Who knows, but if I worked at a bird related startup it might have been called Canary, which also makes sense to me. Who cares what we name things, just have good documentation so it's readily discoverable.
I still don't understand what some of our stuff does and it has common names that are descriptive, because documentation sucks. They could be called Widget and Whoozit for all I care, as long as there is documentation!
Counterexample: having a family of libraries for writing tests that is named "Testing Library" is terribly confusing.
Yeah, that would be confusing. I'd personally suggest making them a bit more specific and, if you can, creative—just not so creative as to be unintuitive to their purpose.