From experience, this is thew worst possible decision to make in anything apart from the smallest of organisations (i.e. where production is small enough that all the engineers know (like, really know inside-out and have it all in their head - not just "aware of")), at which point you don't have much to worry about when it comes to renaming something.
Please, put yourself in the shoes of someone else. Someone who doesn't know what "PonySparkles" or "B-52" or "Starling" or "Hydrogen" or "Pokemon" or "PapaSmurf" or "ProjectSmart" or "Dylan" or "Everest" or "Kathmandu" are, or doesn't get the "joke" about why this thing is called "TinkerBell" and not "BroadcastService".
The original owners/authors will inevitably leave the company, and new-starters won't know what the names are unless someone tells them (and even then I can promise you they'll be thinking "why did you call it that?"). Discoverability will also be poor, so someone else in the company will probably end up duplicating your effort because no one realised that we already had BroadcastService, or struggle to understand why they cannot get <some simple thing working> because it is impossible to understand what needs to happen without knowing the Secret Gatekeeping Knowledge of the magic Cute Names they need to know about.
Just look at AWS service names as an example - what the hell does BottleRocket or Textract or Polly or Route 53 mean? You have to go read docs to find out what those Amazon services actually do.
Just please don't do it. Please use simple general words that are descriptive and as obvious as possible.
As per the article: The problem is that descriptive names don't stay that way. Descriptive names turn into misleading names as the things they refer to change over time. And while code can be refactored, it's very hard to refactor a service name, and almost impossible to refactor it away from people's minds.
Cute names are basically the equivalent of calling everything in your code "variable_1", "project_2". Descriptive names may be misleading, but at least they attempt to capture the intention rather than completely disregard it.
From experience, this is thew worst possible decision to make in anything apart from the smallest of organisations (i.e. where production is small enough that all the engineers know (like, really know inside-out and have it all in their head - not just "aware of")), at which point you don't have much to worry about when it comes to renaming something.
Please, put yourself in the shoes of someone else. Someone who doesn't know what "PonySparkles" or "B-52" or "Starling" or "Hydrogen" or "Pokemon" or "PapaSmurf" or "ProjectSmart" or "Dylan" or "Everest" or "Kathmandu" are, or doesn't get the "joke" about why this thing is called "TinkerBell" and not "BroadcastService".
The original owners/authors will inevitably leave the company, and new-starters won't know what the names are unless someone tells them (and even then I can promise you they'll be thinking "why did you call it that?"). Discoverability will also be poor, so someone else in the company will probably end up duplicating your effort because no one realised that we already had BroadcastService, or struggle to understand why they cannot get <some simple thing working> because it is impossible to understand what needs to happen without knowing the Secret Gatekeeping Knowledge of the magic Cute Names they need to know about.
Just look at AWS service names as an example - what the hell does BottleRocket or Textract or Polly or Route 53 mean? You have to go read docs to find out what those Amazon services actually do.
Just please don't do it. Please use simple general words that are descriptive and as obvious as possible.