Names of products should be memorable, and probably cute.
Names of technical items (e.g., function names) should be descriptive.
Names should be cute, not descriptive
401–410 of 498 posts
Re: Names should be cute, not descriptive
#402Earlier quoted context omitted.
I say, go for both. Go all Boaty McBoatface on that thing. Boaty McBoatface is silly, but it is unarguably a memorable name for a boat. There are other, less silly, but equally memorable (and maybe even cute) descriptives out there. On a different note: if you are presented with an either/or choice, your first instinct should always be to ask if they are actually opposites or if you can also have both if clever.
> memorable name is it ever a problem in software engineering, that you can't remember what that component's name is? I find it more of the problem when people make a good library that solves a problem with a predictable name, but then they give their library some other cute name, and maybe they don't do SEO well on package repositories (why would they, software engineers). So, when I look npm up for that problem, th…
> I find it more of the problem when people make a good library that solves a problem with a predictable name, but then they give their library some other cute name
This is why I said Boaty McBoatface. You look for Boats? It has "boat" literally two times in it's name.
Re: Names should be cute, not descriptive
#403Earlier quoted context omitted.
100%. I was at a company and they kept renaming the internal name to match the marketing name. We had 3 names for some older tech and 2 names for the less than a year old service. I strongly recommended that we should adopt the original name as a "codename" and use it for code and internal technical documents. Marketing should absolutely have full control over the user visible name. But technology has different needs…
Related-ish, but Apple's macOS APIs are peppered with references to NeXTSTEP. I find this charming. For example, NSView (spelled out - NextStepView). https://developer.apple.com/documentation/appkit/nsview
NeXTStep used "NX" prefixes, and its successor, OpenStep, used the prefix "NS". "NX" stood for "NeXT", "NS" stood for "NeXT and Sun".
Re: Names should be cute, not descriptive
#404Earlier quoted context omitted.
Isn't that why namespaces were invented? You put those in the namespace `AdServer: { Server, Renderer, Storage }`
Sure, but what if the AdRendererServer is written in Python and the AdServer is a Rails app? These tend to get turned into acronyms like ARS and AS, and then “ars” and “as”. So a meaningless grunt or an evocative, memorable word?
Namespacing can exist in more ways than just in code. Surely you could have your server, renderer, and storage components in one repository under the Ads product:
Ads/
Server
Renderer
StorageRe: Names should be cute, not descriptive
#405There’s some history here people are missing. Back in the day we used cutesy names for boxes , and we did it for good reason: Back then, before cloud services, when you were building out an application, you would build one computer, load it up with some services, and then when that one started performing poorly you’d add another computer and move some of the services off. You would frequently rebalance which services…
My first role had machines like: ob-la-di for the reporting services server, ob-la-da for the nightly build server, etc. I always hated it. In aggregate the services on these servers belonged together. The sysadmin was just extremely casual about his role and thought it was funny and cute. I eventually got sick of going to the wrong server all of the time and mapped them more logically in my hosts file. It's not like he couldn't have done this originally or eventually, but well into the 2010s he was using song titles for server names.
Re: Names should be cute, not descriptive
#406Earlier quoted context omitted.
> descriptive names might eventually become non-descriptive It's worse than being non-descriptive- it's that they become misleading . "Cute" names don't tell you anything. Formerly descriptive names tell you the wrong thing . This, in turn, means developers can no longer trust that a descriptive name is accurate. It plants a seed of doubt in a developer's mind about other names. It tells them that, here at WidgetCorp…
> It's worse than being non-descriptive- it's that they become misleading. if you find that something has drifted to the point of being misleading, then rename it it's software not hardware or comment on code reviews that change the functionality to the point where this is a problem
> if you find that something has drifted to the point of being misleading, then rename it
Sure, this is the proper course of action when that is an option, but...
> it's software not hardware
...if the "software" is a 3rd-party library that external stakeholders are consuming, then it may as well be hardware, because those class and method names represent an API contract that the library's users expect to remain consistent. Which means changing them involves a non-trivial change management and versioning process. Even when the code is internally-facing only, in a large enough codebase it's often the case that multiple teams (and their respective codebases) depend on those names, increasing the complexity of a rename.
> or comment on code reviews that change the functionality to the point where this is a problem
Again, this is the right move if it's available to you. We don't always have that luxury if the names have already gone off-course by the time we first encounter them. Which is often the case an an older codebase that has been written and re-written by many employees who have come and gone over time.
Again, I continue to believe that I'm a member of the "do NOT use cute names" camp. But I'm seeing a lot of cavalierness in these comments about "just rename it, what's the big deal?" and experience tells me that it's not always that easy.
Re: Names should be cute, not descriptive
#407> It's impossible to predict with certainty how your software's requirements will evolve over time. And if you don't know what your software will need to do later, you don't know what the ideal factoring will be then, let alone now. It will almost certainly change over time. If you follow the idea of the "Single Responsibility Principal" with discipline, then you should create a new piece of software if changes to it…
..Or create a new product with a standard connector for both, an adaptor for lawn mower and another one for mulcher, using the same engine. It can be called Mulchwer - cute and descriptive! When the company inevitably invents a new adaptor, say a snow blower for clearing the sidewalk, the product can be renamed Mulchwer X, or Multi-Mulchwer Deluxe. It's now an all-purpose product with a set of adaptors for any front/…
We call these tractors, although the adapter is usually on the rear! And I think they are gaining some AI.
Re: Names should be cute, not descriptive
#408Earlier quoted context omitted.
Related-ish, but Apple's macOS APIs are peppered with references to NeXTSTEP. I find this charming. For example, NSView (spelled out - NextStepView). https://developer.apple.com/documentation/appkit/nsview
NeXTStep used "NX" prefixes, and its successor, OpenStep, used the prefix "NS". "NX" stood for "NeXT", "NS" stood for "NeXT and Sun". https://news.ycombinator.com/item?id=15973609
The comments on your linked post seem to indicate that NS referring to "NeXT & Sun" is highly controversial.
Re: Names should be cute, not descriptive
#409There’s some history here people are missing. Back in the day we used cutesy names for boxes , and we did it for good reason: Back then, before cloud services, when you were building out an application, you would build one computer, load it up with some services, and then when that one started performing poorly you’d add another computer and move some of the services off. You would frequently rebalance which services…
A funny example of this can be found by looking for nameserver entries for vatican.va. An apostle and arch-angel for the Vatican, mixed with an Egyptian god and apocryphal character for the Roma exchange they partner with.
vatican.va. 3600 IN NS john.vatican.va.
vatican.va. 3600 IN NS michael.vatican.va.
vatican.va. 3600 IN NS seth.namex.it.
vatican.va. 3600 IN NS osiris.namex.it.Re: Names should be cute, not descriptive
#410I could not disagree more. > Trouble is, names are hard to change. No they’re not. People just aren’t determined or organized. > It's impossible to predict with certainty how your software's requirements will evolve over time. You don’t need to predict it. You evolve things as needed, including names of components of the system. The idea that you need to pick a generic name because you don’t want to specify exactly w…
I utterly disagree with you. After 30+ years of doing this, I almost always despise "descriptive names" - they are almost always wrong, generic, and hard to say/type. They are difficult to change, and even if you do change them, you just end up with another crappy descriptive name. "database-writer" or "user-database-writer" or "database-post-writer" or "event-logger" or "event-logger-2". While every once in a while…
I too have been doing this for decades and I completely disagree with you. The vast majority of names I see are mostly correct, with the exceptions representing the areas with most technical debt. It is far easier to remember the handful of services with bad names do than to have to remember the mappings for every piece of functionality. If there's an order service, it's pretty good bet it will process orders. If there's a search service, it probably does something with search. Does it also do billing? Maybe. Then that's one I'll just have to remember. But it's way easier to remember "some bonehead put billing in the orders service" than "orders and billings is snowwhite, search is sneezy...or was that dopey?" And if you have an orders service that doesn't do orders...well, there's clearly some very bad technical debt in that area. That's worth knowing too.