Horrible advise in this post, names should be DESCRIPTIVE/MEANINGFUL because a critical rule of marketing says that provide solutions to people who are already looking for it. Therefore if you want your service/product to show up on SEO/Search, use descriptive name and not a cute name that no one knows what it means.
Names should be cute, not descriptive
231–240 of 498 posts
Re: Names should be cute, not descriptive
#232Re: Names should be cute, not descriptive
#233Earlier quoted context omitted.
> No they’re not. People just aren’t determined or organized. You just provided your own counterargument. People naturally aren't determined or organized, that's why names are hard to change. You can't change human nature, you can only work around it, and cute names are a solution for that. Cute names work even if people are disorganized, and they are. Furthermore, cute name, rather than purely generic or descriptive…
> You can't change human nature, you can only work around it Yes you can. When a person becomes a civil engineer they are trained to change their nature so that when they design a bridge they do it in a way that meets all the standards with full documentation rather than the way they would sloppily design their dogshed at home.
But isn't that exactly the "work around it" part? There are full standards one needs to adhere to, so you basically work around the sloppy part of human nature.
Re: Names should be cute, not descriptive
#234Earlier quoted context omitted.
> Trouble is, names are hard to change. > No they’re not. People just aren’t determined or organized. This is very untrue. Many moons ago my company changed its name, and we still have the old name lingering around in stupid places. There are e.g. several third-party services which simply won't let us change the name and carry our data forward, or where proper migration would take eng-months. I guess you could say we…
I too have worked in code bases that have included one or two company name changes in them, and it can really add unnecessary noise to the source. So I think this is actually a counter-argument for using "cutesy" names - swap "cutesy" with "branded" names, and you may see what I mean. This is a basic thing I learned early on and teach others - do your best to not include the name of a product in your codebase, rather…
The problem with using a brand name in code is that the audience for the brand name is external to the company and subject to change due to conditions in the market.
The problem with descriptive names arises when it becomes hard to distinguish between components named “AdServer, “AdRendererServer”, “AdStorageServer”.
It’s liking naming a WWII bomber “Fuddy Duffy” and painting Elmer Fudd on the side. It’s a lot easier to find and talk about than K297400!
Re: Names should be cute, not descriptive
#235> 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 would drift too much from what it was named. If you have a lawn mower and you start trying to use it as a mulcher as well, you will be a lot better off creating a new product called a "mulcher" intended for just that purpose.
Re: Names should be cute, not descriptive
#236Help me, for I am socially malnourished. This is a joke, right?
Re: Names should be cute, not descriptive
#237Earlier quoted context omitted.
> Trouble is, names are hard to change. > No they’re not. People just aren’t determined or organized. This is very untrue. Many moons ago my company changed its name, and we still have the old name lingering around in stupid places. There are e.g. several third-party services which simply won't let us change the name and carry our data forward, or where proper migration would take eng-months. I guess you could say we…
There are quite a few of these. Jenkins has "Hudson" in its internal namespaces. Various Microsoft products have their old names in classes. Once a name is used externally, it doesn't matter how organized you are, there are uses outwith your control.
NSeverything in apple APIs is another good one I think.
Re: Names should be cute, not descriptive
#238No no no no no. Please never ever do this. 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…
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.
Re: Names should be cute, not descriptive
#239I'm strongly in the camp of cute names. They are memorable identifiers, nothing more.
Cutesy names are greppable, meaningful names are not. 'billingmurray' Vs 'account service'
Giving meaning to a service through its name is also mostly nonsense, since no name will convey enough information about it's responsibilities for it to be meaningful anyway.
Besides, all of the systems and services you use are either acronyms or cutesy names already. Docker, Linux, Unix, qwerty etc. They're just labels.
We have Spotify, not music.com, and Amazon, not books.com.
Re: Names should be cute, not descriptive
#240Wish I read this before I named gonna my dog "Noise Maker".