> 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 what a service does and instead want to change responsibility constantly without change its name is weird.
> And then the cherry on top, the final nail in the coffin of descriptive names: They're just too hard to say and remember, and they're no fun.
Why are software engineers like this? My idea of fun is not simply calling things Magneto and Cyclops, or Potter or Dumbledore, or Denali and Everest, or Wham and Bam, or whatever else. You know what is fun when it comes to work? Things that work, are named appropriately, are understandable, and people not needing trivialities. The amount of stress coming from things going in the opposite direction makes people’s lives much less fun.
I know software engineers like to blame management for all their problems, but I have come to the general conclusion that software engineers cause their own problems.
I’ve worked at companies that name things like this (sadly, it’s most companies), and you can work there for months before you know what <cutesy name> does. It’s because it’s generic and because a “fun” name was chosen, its responsibilities have not only changed but its number of responsibilities have changed. By not needing to change the name because it’s not descriptive, it naturally starts to become a catch all monolith because one has removed all friction to not doing so. You end up with the situation of not being able to say “Startrooper does <x>” because it doesn’t just do <x>. It does a million other things because “Startrooper is where we put things because we don’t want to create a new component or service”.