Software names and component names can be really hard to change though, especially because those names tend to leak into the public API.
When my company got acquired, they rebranded our C++ library, but to this day the old software name persists in the namespace it uses because they weren’t willing to break every customer’s code. The name of the software can become part of the API in lots of ways (URL component, C++ or Java or other namespace, executable file name for scripting, etc.).
So yes, software service and component names are hard to change when customers start relying on them.
So why not rename versions to cutesy names then? Function names? Argument names? That way, you never have to rename anything and can just change the behavior.
Sorry for the wall of text. I found your question super valuable for crystallizing my thoughts. TL;DR: Abstract names are good when your scope is poorly defined and hopefully your functions aren't like that. If they are, maybe consider abstract names for them.
The author's argument is that large software components tend to shift in scope over time, so a very concrete name will become incorrect as the scope starts to misalign with the name. A hard-to-change concrete name at that point becomes a misnomer, and it would be better to have had the abstract name from the beginning. I'm resisting the word "cute" because I don't think that's really the core here -- the question is if names should be abstract or concrete, and the abstract names can be whatever aesthetic you want.
Why not use abstract names at smaller scales? I can come up with a couple of reasons:
First, smaller-scale constructs are easier to predict. The project as a whole might go in a ton of different directions and get pressed into service for a ton of different tasks. But my encodeBase64 function will only ever do one thing, and I can predict that pretty reliably, so I can give it a concrete name. I hope to someday find a codebase where every function is like this ;).
Second, smaller-scale constructs often have names that are easier to change. Most functions you write don't end up as part of some API, and the ones that don't can be given specific names with the understanding that it's easy to change them later if you have to. Obviously, this doesn't always apply.
Third, smaller-scale constructs suffer from less scope drift. I find that the pressures to change scopes are generally on the project as a whole, and a large part of extending a system well is to adapt the project as a whole to those pressures while protecting each individual component from them as much as possible. If you can do this well, each small component gets to be more stable than the project as a whole and can support a more concrete name.
Finally, maybe you should sometimes! Maybe you have a function that has had massive scope drift such that the name no longer applies. It started life as updateCustomerBalance, but now it's reaching into the supplier database too, and appending to a financial report, and hitting some backend servers at one of your vendors. The name is now actually misleading. (Ideally we'd refactor, but this article is just about naming.) It might be better with a highly abstract name -- if you don't like the cute route, something like executeBusinessLogic is abstract in the same way. It might be more honest than the specific-but-wrong name.
The name gets repeated in so many places if it's important. Documentation, code, URLs, databases--even just finding all the places you need to change it involves a ton of work.
> The name gets repeated in so many places if it's important.
like the parent points out, the named thing is likely "important" precisely because it had a non-descriptive name to begin with and engineers added things to it they shouldn't have
if it had a descriptive name then other functionality would've been put in their own module
See my other comment in another reply, but are you suggesting that it's better for something to keep the same name while also changing its behavior and purpose? It doesn't make any sense.
In a large enough project, this sometimes results in pull requests covering hundreds of files. While the renaming itself may be a simple task, getting multiple reviews takes a lot of effort and management may have other priorities.
I have renamed a large-ish service that was integral to the whole system before. For one, it wasn't that hard. And secondly, it usually reveals some existing issues and architectural deficiencies.
By doing this your names aren't in 1NF and you're making it harder than needed to do updates. If your names are cute/unique then changing, expanding, or reducing service responsibilities just means updating the single document that says what Dreki does.
