33 ms·

Names should be cute, not descriptive

• nazka 4y ago
  This is really AWS naming vs GCP naming.
• nathan_gold 4y ago
  In organization chart data, there are people with cute names (John, Jane) and there are positions with descriptive names (Head of Product, Head of Sales). People's responsibilities change but their cute name does not. But you might not know everyone's cute name, and you want to know who to talk to when something was sold that can't be fulfilled. So you look up Head of Sales in the org chart. Perhaps having two names is what is needed as in organization charts.
• allenng 4y ago
  I am so sick of everything having a cute name. Projects can have a cute name; components should not. Imagine if cars did this. You'd get into your car, and it can have a cute name because it's one name to remember and your car can just be a "Jetta", but the "steering wheel" should be called that. Otherwise you can't go anywhere because you're not sure if you should chauffage the afiafi before you cosmo the thanos. chauffage: french for "warm" afi afi: samoan for "motor" cosmo: from the Jetson's Cosmo Spacely, maker of sprockets thanos: no logic whatsoever, I just like the movie (and a bit of whimsy is cute, right?) --good luck trying to figure out what it refers to, I'll probably be gone from the company by the time anyone notices People complain that naming things is hard, but I argue that it's hard if you don't have a good understanding of what the thing is.
• l3uwin 4y ago
  [dead]
• cglong 4y ago
  I was on a team that used cute names. It was fun during the development cycle, but super annoying when you're dealing with an outage. Not only did we constantly get misassigned tickets, but it can be difficult in that moment to remember if you're supposed to engage the Dynamic Pterodactyls or the Hopping Hippos.
• ashton314 4y ago
  I've liked "cute" names that are related to their original responsibility in some way. E.g. we had a messaging service called "McFeely" after Mr. McFeely's Speedy Delivery Service from Mr. Roger's Neighborhood. When someone gets onboarded, they'll encounter these names and will have to ask. It's a short anecdote, and it sticks. I'm personally a fan of these, as long as the stretch isn't too far. Themes around names can be nice, too. (As with the above, Mr. Roger's Neighborhood.)
  • doctor_eval 4y ago
    Yeah I nearly posted the same thing. We had a service called "petal" which did settlement - "settle petal" is a bit of Australian slang.
• camdenlock 4y ago
  [flagged]
  • doctor_eval 4y ago
    Are you sure you linked to the right thing? https://news.ycombinator.com/item?id=34271510 https://news.ycombinator.com/item?id=34271510 > Internet socialists / communists / transhumanists seem to infuse their content with a “chibi” vibe, filled with cuteness and hearts. Disagree with them politically, though, and watch out. The sunshine and roses suddenly become bloody slavering fangs.
    • camdenlock 4y ago
      I’ve never been more sure.
  • meindnoch 4y ago
    Flagged to death. Sigh… Kinda proves your point.
    • operatingthetan 4y ago
      Probably because it appears they are fishing for a political fight, and they are referencing their own vaguely related post from four days ago as if someone else wrote it ten years ago.
      • doctor_eval 4y ago
        Right? Also, where are the "bloody slavering fangs"? It's just a blog post about whimsical naming. Some people will agree, some will disagree. Hardly a touchstone of "internet communists" or "transhumanists". And a bizarre perspective, considering who is behind recent events in the USA and Brazil.
      • ummonk 4y ago
        How is a comment talking about whimsical content "only vaguely related"?
• AceJohnny2 4y ago
  I've found this practice very useful when naming servers, which is an idea I picked up from the Debian project's infrastructure. A physical machine will have a cute hostname, and then the actual service it provides is a CNAME (DNS alias) to it. That way, the physical identity remains steady, but the responsibilities (CNAME) can move around (usually because of upgrade)
  • ilyt 4y ago
    I think it's excused if machine fulfills more than one function at once or needs some distinctor among many that fulfil similar function. If it is a LDAP server in DC1 it should just be "dc1-ldap" or "dc-ldap1" if you have few in redundancy (with actual service being either under "ldap" or "dc-ldap"). But if it is a kitchen sink server running a bunch of services, eh, mjollnir will do, and if you do "ssh ldap" you will ssh to server that hosts LDAP service, regardless of what cute name it will have
• jupp0r 4y ago
  Just don't apply this to variable or function names please, thanks!
  • kleene_op 4y ago
    What? You don't want to sift through hundreds of pokemon and anime characters names totally unrelated to the variables and functions of the API you need to use for your job? I'll just write "not a team player" in your annual review.
    • dottedmag 4y ago
      I'm going through it right now, refactoring https://humungus.tedunangst.com/r/honk https://humungus.tedunangst.com/r/honk honk, zonk, honker, dunk, xonk... the list goes on. This is supposed to be ActivityPub server. Fun. Not.
      • tgv 4y ago
        > reverbolate ... grapevine ... bunchofgrapes I thought you were kidding, but you're not. Sad.
      • jeroenhd 4y ago
        It's like trying to learn frontend dev tools all over again. Too much gulping and grunting yarn for my tastes. I hear somehow bunnies are involved as well these days?
• duffmancd 4y ago
  Reminds me of [0]. At work we tend to create backronyms for/from the cute names which is our way of having our cake and eating it too. [0] https://youtube.com/watch?v=y8OnoxKotPQ&si=EnSIkaIECMiOmarE https://youtube.com/watch?v=y8OnoxKotPQ&si=EnSIkaIECMiOmarE
• PragmaticPulp 4y ago
  Cute names are fun when for a few special things here and there. Cute names are a nightmare when a company has accumulated hundreds of quirkily named things that you have to memorize just to navigate through the basics of trying to get your job done. New hires suffer the most. It’s an extra layer of company-specific jargon that you have to learn to even begin to understand what your peers are talking about.
  • doctor_eval 4y ago
    Yeah but surely there is a directory somewhere that explains this? I mean - the problem is not the number of names but the number of services. A new hire still isn't going to be able to work out what a service does just based on the name, regardless of how whimsical or apt it is. "policy-engine" might seem to be a good name for a service, but it's only one level below "kevin" in terms of opaqueness, especially when there are probably several policy related services.
    • drstewart 4y ago
      >Yeah but surely there is a directory somewhere that explains this? No, there's 5 different directories in 3 different formats compiled across the last 8 years representing the state of 80% of terms at the time it was last updated, half of which disagree with another version.
      • ls15 4y ago
        I can confirm this
      • doctor_eval 4y ago
        I gotta say, I think that's actually just bad technical management, so I suppose it's probably common. Although I will admit Conway's law here. Nevertheless, the same phenomenon that leads to multiple directories will also mean that supposedly "descriptive" names, will not be.
    • ummonk 4y ago
      "policy-engine" is an example of a name that is neither cute nor descriptive
• rikkuri 4y ago
  Descriptive name guards from feature creeping because every one understands the scope of service. If it is always tempting to add new features to the existing services, creation of new services should be done to be easier.
  • paxys 4y ago
    You really think a name is going to hold anyone back from this?
    • resonious 4y ago
      Right, the article itself actually uses this as a compelling reason for cute names. If I release "X service", then it inevitably becomes "X and Y service" and the old name is now misleading.
    • drewcoo 4y ago
      I think code reviews might.
• raydiatian 4y ago
  Yeah this seems like a terrible argument. Here is what onboarding looks like, if we all followed this: “Okay so, the part of the app you’re working on is weeble-wobble which handles transactions. Weeble-wobble interfaces with poopy-leg to create financial reports, and with screaming-kidney to do fraud analysis.” Maybe this is fine for devops? I mean, if pets, not cattle is the regime within the org
  • brianpan 4y ago
    Don't forget about Galactus, the all-knowing user service provider aggregator. https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ
    • raydiatian 4y ago
      Okay so everything I said is apparently already a much more thought out rant
• meindnoch 4y ago
  This trend is so painfully cringey…
• MrGilbert 4y ago
  I wouldn't necessarily call them cute, but "Odin" (my phone), "Tyr" (my NAS) and "Thor" (my home server) would surely agree.
  • knorker 4y ago
    Cute names don't scale. You can name your servers after star trek characters, and routers after star wars characters, only if you have very few.
    • MrGilbert 4y ago
      Sure, yes - something that's not an issue at my home, but surely will at other places. Regarding naming - Middle Earth should have many possible names at hand.
      • knorker 4y ago
        Star trek has many names too. It's just that they get more and more obscure. Which is fine if it's just you. But if it's a company and you hire someone who doesn't rewatch TNG every weekend, then it doesn't help that you know the daud's wife's name. And that would hurt the business. I'm sure every character in the star wars cantina has a name. That's not the point.
• FeepingCreature 4y ago
  > I don't want to be the one to advocate for delaying features so we can rename broadcast-service to broadcast-and-new-responsibility-service. That's going to be an unpleasant conversation with your product manager, for good reason: Because this never should have happened, and it's a waste of time to change the name. Sounds like there's a workflow problem around renaming services?
• paxys 4y ago
  It's funny that the author brings up the point about names being for identity rather than responsibility. Historically, names have often signified both. Ask anyone called Smith or Cook or Archer.
• extr 4y ago
  Nice theory. In practice all this does is make it harder to onboard new people. Quick test: It's your 2nd week on the job. Some core system just went down, and you've been assigned to figure out what service is causing the trouble. What makes for easier, more transparent reading of error logs, the name "ServiceRouter", or the name "Trainstation"? It's not just a matter of the name being perfectly descriptive for any and all responsibilities, in zero-context situations it can be good just to give a hint that yes, this is a service, and yes, it at one point handled routing, so it seems like an okay place to start. The more obscure the name, the longer I spend reading about some obscure same-named repository and wondering how it's related to the issue at hand. That said, I think a certain degree of whimsy is definitely acceptable (necessary?) in the workplace and should be encouraged. I can support silly names for the sake of having fun. But maybe if it's something important, foundational, try to remember it may not be as fun for someone 5 years down the line at 2AM.
  • doctor_eval 4y ago
    Who would assign a core system failure resolution task to a newbie who's been there two weeks? Also, per the article, the problem is that "ServiceRouter" maybe isn't as obvious as you might think. The actual HTTP routing might be done by "HttpPathInspector". "ServiceRouter" is actually a non-core message router for analytics. Naming is hard.
  • xlii 4y ago
    I've been in situation where "ServiceRouter" was also doing feature flagging so when debugging 5-year old impossible to solve issue no one looked at it (because, well, it was ServiceRouter not ServiceRouterAndFeatureFlaggerAppendage, in spirit of the article) - YMMV. Another fun story I recall happened when server technician had to replace faulty HDD in RAID array. We ensured that the serial numbers were correct in correspondence yet still technician replaced the wrong one. When we complained we got into funny argument that we should use color code to designate HDD. Serial numbers are hard to pass and easy to confuse (especially since they were next to each other). But color coding wasn't provided to us, customers - we couldn't use it even if we wanted to. Naming is hard but descriptive name doesn't guarantee correctness or helpfulness just as non-descriptive wont ease understanding or improve communication without proper directory or conceptual mapping. Does DatabaseServer-EU-259-aed6f give more information than "dumpstation" in scenario where it relates to single server wordpress blog. In the end it's still about difficulty of naming, middle ground and consistence. Ubuntu for years used letter coding with animals and it worked. MacOS uses naming scheme for releases even though iOS and iPadOS are numbered only. Some people would be confused that Windows 95 is after Windows 3.11 and before Windows 10 and Windows 11. Not sure if Docker still use cutesy auto generated names for containers but it was fun to use. Naming is hard.
• gorgoiler 4y ago
  They’re both right, of course — the author and his colleague — and this blog post makes an excellent point as to why. I will switch from descriptive to cute once I’ve reached a certain level of abstraction. That level can best be defined as the level where I will need to start advocating for the idea with other engineers. A new ssh wrapper for automating access to the manufacturing robots? example.factory.sshtool A log file parser for extracting text-only errors across multiple robot.log lines into structured error objects? example.factory.logs A quarter-long project to build a new abstraction over all our thirteen different categories of manufacturing robot we have deployed on site that replaces a bunch of shell scripts written by the former CTO, and then actually replace all those shell scripts with the new thing, with tests? example.factory.duckling I’d promote it as being named after how ducks imprint on their mother and follow her lead. Kind of a nod to the robots, but also to the former CTO. Cute names can feel a little saccharine but it really helps build advocacy obviously — it’s ultimately a branding / marketing exercise. If you do that day-in day-out at the level of the ssh tool or the log parser — projects that should ideally have a low level of controversy compared to the shell script rewrite — then people are going to get annoyed with you.
• mastermedo 4y ago
  When a bunch of those names accumulate, you pay a high onboarding price, not only for newcomers, but also for people who don’t read your changelog. - Oh, _gfuby_ can now monitor my instance in production in addition to being a code versioning system!?
• ppeetteerr 4y ago
  While scope expansion is a potential issue, a service by its nature should not inherit scope outside of its core responsibility. If it does (an auth service with some type of user information is clearly taking on more scope than it should), a practical name will reveal that right away. The issues with practical names mentioned in this article are pretty small when compared to the very real issue of understanding cute-named services. If AuthService goes down, I know what that means. If Balthasar goes down, I now have to understand what that is, look up documentation, find the right team, etc.
• fexecve 4y ago
  Baby, meet bathwater. "Names are hard to change" is supposedly the reason to give things meaningless random names. Great, now you get the worst of both worlds, the meaningless name is now synonymous with a purpose (the very thing you tried to avoid, well, tough luck, that's not how human psychology works!) AND newcomers to the company/org will have zero idea what "galactus" and "goatpen" are or what they do.
• lifeisstillgood 4y ago
  Interesting, cute even. But I will stick with boring law firm names. Firstly when I was a so-called manager cute project names were a nightmare - who could remember what "project mayhem" was - lift and shift half the the data centre or was it refactoring the stupid accounts hack. Project refactor-accounts-monthly-charge is something at exec level everyone can remember. It's fine for project-negotiate-possible-sale-of-dutch-office to be called project mayhem, because powerpoints get acciendetaly shared, emails get read, but there aren't many of those. Secondly Sam used to be called Sam Smith because he was the smith. If he becomes used for something else people will create a directory (in their heads or in reality). And that's the key here. Directory services are way easier to manage
• eyelidlessness 4y ago
  I still lament the time when a former team had to rename a service referencing a noble sea creature to its perfunctory backend purpose, and our corresponding service with a rhyming name referencing hair loss had to be renamed to reflect its unambitious web target.
• dopidopHN 4y ago
  Whatever, but just don’t use starwars or Marvel names.
• knorker 4y ago
  Cute names are awful. What, you don't remember every Star Trek character? What, you can't spell every Greek philosopher? Really, you don't know which are star names and which are galaxy names? And then there's the reuse. Which project mayhem is this?
• beshrkayali 4y ago
  The mistake the author is making is that indeed his friend Sam will still be Sam (even if he changes jobs) but he is a human that exists regardless of his function. Variable names’ on the other hand only exist to serve a function, when the function is gone the names that refer to it should be gone too. If you have a ml-worker node and you no longer need an ml worker, you refactor the code to remove those. It’s much easier to remove than to rename, and consistent mild refactoring ( or code massage if you will) means you’re more likely to remember what lurks in the dark corners of your code base.
• godelski 4y ago
  Cute names are human readable. Descriptive names are hard to search for and hard to say. They are often overloaded. Best are cute but descriptive acronyms. Your brain remembers cute more, so optimize for your brain.
• kqr 4y ago
  TFA is based on a false dichotomy. You can have both. At one of my latest workplaces, there was a system of loosely connected, branching event-driven processing nodes where the events accumulated additional data as they rippled through the system. In the code and UI, this was represented as "heroes", coming from "guilds", "embarking" on "quests", eventually meeting their "reaper". On their quests, they entered "locations" containing "pickpockets" that pulled things out of (and put things back into) the hero's "inventory". This cute-but-descriptive vocabulary really helped less technical people grasp how it all fit together -- even if it was a complete lie and gave the wrong picture of how the system worked under the hood. (In particular, it is a common misconception that the heroes are driving the action by choosing locations to go to, when in fact it is the locations (processing nodes) that pull heroes (event data) along. But that misunderstanding never caused a problem in the four-ish years I worked with the system.)
  • Macha 4y ago
    Brew tries this: You write software formulas (packaging scripts) into bottles (binary packages) in your Cellar (installed packages directory). Some software, such as GUI applications, uses casks, because casks are a different type of container. If you want a new source of packages, you add a tap. I would take packages, packaging scripts, package repository, binary packages and GUI packages any day over brew's attempt at cutesy terminology.
    • kqr 4y ago
      I think there could be a difference here: you're already familiar with the domain brew operates in. The system I'm speaking of were extensively used and configured by people who had no prior experience with event-driven, branching logic, nor any familiarity with the terms involved. You can still argue it would have been more efficient to teach them that domain first, then teach them this particular system for it. Maybe. I'm saying as far as I can tell, there was no drawback to the cutesy terminology for the intended users (nor for developers other than in isolated cases) and it seems to me they learned quicker with that framing than without it.
      • 4y ago
• ptr 4y ago
  Since services are basically modules in monoliths, does that mean that we should have cute names for those as well?
• styluss 4y ago
  having worked in a company where project were named after marine life, I changed my mind, no cute names.
• lemper 4y ago
  nah, i'd stick with boring law firm names. people come and go and i don't want to inherit a project from john doe from 5 years ago that used a really obscure reference to gorean lore or some other "cute" names.
• germanfella 4y ago
  I made an account on HN because this is the worst post I have ever read here. NO!!!! DON'T USE CUTE NAMES!!! I am currently working with a big company for my apps and it is full of cute names which are the biggest problem for me. To launch an app you have first to integrate the Zaamla-Service into your IDE. Then just patch things up with Pimble, upload the signed HIMA-Package into the Katala and activate after that Zanik on the Bremmis platform to include the Mumana-Service to distribute the app. What? It doesn't work? That's because you didn't integrate the Jonhson-Rod stupid? How is it supposed to work without the Johnson-Rod? Are you even a real programmer?
  • pprotas 4y ago
    I’m sorry but I just have to link this classic video, this comment reminds me of it: https://youtu.be/y8OnoxKotPQ https://youtu.be/y8OnoxKotPQ
  • nextlevelwizard 4y ago
    Sounds more like architectural/tooling problem. We use pretty much random names for our servers and other hardware, but all of that is abstracted so during normal operation you don't even know what thing you are using unless you want to for some reason. I am not really for or against using names instead of numbers or whatever, because I should never even need to care if things are done right.
    • 28304283409234 4y ago
      I heard that Ifthingsaredoneright is a really nice planet to visit one day.
      • EFreethought 4y ago
        It's better than being on planet someonewasintentionallystupid.
  • Gigachad 4y ago
    Doesn’t sound like that would be any easier with different names
• geysersam 4y ago
  This problem is quite interesting from a theoretical point of view. How to structure a program to be less dependent on its name? Would it be possible to have a single source of truth for names? So that if you want to change a name, that's a single line commit. Problem is, if the name is dynamic we'll have to refer to the name using another name.
• tgv 4y ago
  If your problem is that names are too descriptive, give your services a number. Because your naming fun will run out of steam, and it'll become cringy as heck when some engineer who thinks (s)he's funny assigns a cute name to a service that makes the rest of the company gag. It's quirkiness for the sake of showing off, not to solve a problem.
• bobbiechen 4y ago
  I'll put in a vote in favor of cute names, in the specific scenario of talking (out loud) about specific services - it's less clunky and personally, way easier to correctly parse cute names than common-words-which-may-combine-into-a-service-name. To take some examples from public cloud: "We can put that data in Cloud Storage Archive" vs. "We can put that data in Glacier" "This service runs as a function in Azure Functions" vs. "This service runs as a Lambda function" "Use the standard machine image" vs. "Use the standard AMI" On the other hand, I did work on a system where all the services were spaceship names, and that was a nightmare to onboard people onto... echoes of https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ , especially as one was named Galactica
  • pbnsh 4y ago
    Was that company by any chance founded by a rick roll sent via an api/sms and has 4 dots in it's logo?
    • bobbiechen 4y ago
      Yeah, it's Twilio - my profile here is easily connected to my work history haha.
• kstenerud 4y ago
  Sorry, no. Service naming is essentially the same argument as module or class naming. We've already had that argument and descriptive names are king for reasons that have been explained to death over the past decades. Could you imaging going through an unknown codebase and finding that all of the names are "Scooby" and "Rumplestiltskin" instead of "RenderPipeline" and "UserInput"? If your service starts taking on responsibilities that render the name non-descriptive, then it's likely taking on responsibilities that it shouldn't, and you need to have a talk with your architect, same as you would with an entirely local app.
• Lapsa 4y ago
  what a weird article... am I blind? where's an example of such "cute naming"? am I supposed to name everything AYAYA now? concise names aligned to business domain are worse because the way we think and responsibilities changes? wtf?!!
• jnsaff2 4y ago
  Dude(tte) is losing an argument so they turn to HN for more arguments by writing a trollish blog post. I find naming to be one of the most bikeshady of activities. Pick something and move along. The more you think/argue about them the worse the outcome. Channel your first instinct but be ready to change it once it turns out to be wrong.
  • fein 4y ago
    Does said argument have it's origins on here? I went to college with this guy (Assuming it's the same Nick Tietz) and thought it was satire, but I have no idea how people change over the years. That or we're on the bleeding edge of Poe's law. edit: It's far too early and my eyes skipped over the first sentence in the article.
• mostertoaster 4y ago
  Wrong answer. Names should be cute AND descriptive. His point is good though. Descriptive names add overhead that might need to be changed. Giving something a cute name but describes its general purpose, means you have a lot of leeway, but if you get to the point where even the general name doesn’t work and you want to change it, then you actually have a new product and creation is better than evolution when it comes to software. Joey, the small service that hops from one place to the next in what seems like ~~ab~~an endless loop, is like a baby kangaroo, and it can even grow into a real kangaroo and do whatever they do, but it isn’t gonna become a fire breathing dragon, and if Joey is trying to be forced into being a dragon instead of a kangaroo, well maybe it’s time to start from the beginning and decide which programming language to use ~~snd~~and go from there. Think of it, instead of writing software, we just write fantasy stories, and the software that tells the story is our product. I don’t know about you but I could probably come up with some cool stories of Joey the baby kangaroo. I’m going to start a company and name all the services and APIs supporting the software after the best characters from mythology, and just start making good characters and then figure out where they go in the story. The story is already written, but the characters have to be fleshed out.
• pbnsh 4y ago
  [flagged]
  • someweirdperson 4y ago
    > ! NEVER USE CUTE NAMES IN ANYTHING ! So I guess you first-born is called pants-pooper?
    • pbnsh 4y ago
      No, I address them as child01-mother01, child02-mother01, child03-mother02 and so on.
      • bryanrasmussen 4y ago
        I like to prepend with year of birth.
      • f4c39012 4y ago
        How are their grandparents addressed?
• pipeline_peak 4y ago
  > The world is boring enough as is. Let's add more whimsy and cuteness through our service and project names. Cute names suck, a list of them obfuscates a development stack to newcomers and they’re just hard to take seriously. At my company, we have Jira, SumoDB, and Java. I wonder what that means to a Business Analyst, surely they know straight away. The hipsterdom in the tech world is cringe. Go teach (force) your kids to learn Python with the children’s book you wrote. Oh and don’t forget to give it a cute name that sounds Japanese or like a type of tea, we need more of those…We’re totally not going to look back on cute names in 20 years as a silly fad
• sublinear 4y ago
  I only agree if I'm allowed to reinterpret "cute" as easily recognized uniqueness. The motivation for cuteness seems to be a spiteful false equivalence made between unintentionally bad names and deliberately silly names. Good names come from well organized projects. It's sad to hear some would rather name their servers after dolphin species than address the communication problems on a team.
• r_hoods_ghost 4y ago
  Cute names often (not always) rely on a specific cultural context that many devs in the present, and definitely many devs five years down the line, won't share. When people argue for "cute" names over "descriptive" names, what they really often mean is "names that are actually descriptive but only if you understand my obscure nerd joke / spent your childhood playing pokemon". Or they pick a theme and end up trying to stick with it and make something vaguely, but not really descriptive within that theme. It also makes searching for internal documentation a nightmare.
• dbingham 4y ago
  You're optimizing for the wrong things and working with an artificially limited set of constraints. The rule of thumb is that we spend 10x the amount of time reading code that we do writing it. When you use cute names to avoid the pain of name changes when the service changes, you're optimizing for writing over reading. It's a mistake. You pay the cost of a name change once, but you pay the cost of an unclear name many, many times per day. Further, you're introducing unnecessary, artificial constraints. If you need to add new responsibilities to a service that don't fit with in it's existing scope - the correct answer is to make a new service. Granted, some times we don't have time for either a rename or a new service and we have to duct tape the functionality wherever we can. This is called techdebt. It should be documented, tracked, and paid down at a later date... By renaming the service or refactoring out a new one. Attaching arbitrary functionality on to cutely named services that don't have logical coherence is not future proofing. It's really bad software design.
  • Hermitian909 4y ago
    This is good advice in the small, but I think the author is correct for larger services. I can't tell you how many times someone insisted on a name that was "universal such and such" which, uh, turned out not to be universal. More concretely, this is good advice for services that you expect many teams to hook into, and not great advice for services that you think should not expand 1-3 teams ever.
    • dbingham 4y ago
      I think the problem you're speaking to has more to do with attempts at "universal" design. Which actually runs counter to the principal that services should have a limited, clearly defined set of responsibilities.
  • ilyt 4y ago
    > The rule of thumb is that we spend 10x the amount of time reading code that we do writing it. When you use cute names to avoid the pain of name changes when the service changes, you're optimizing for writing over reading. It's a mistake. You pay the cost of a name change once, but you pay the cost of an unclear name many, many times per day. That is for name of variable. Changing a name of whole application can be royal PITA all over the stack, if the "one time change" is "scour every documentation ever produced and change the name there too so people won't get confused. And not just docs, put the name of service as query in Grafana ? Gotta go around dashboards changing that too
• pvsnp 4y ago
  Don't do this. I see these names as just obvious ways to describe what things do like variables. I wouldn't want to be reading code like ``` beeblebrox = zaphod + trillian ``` similarly names of services in architecture diagram shouldn't be undecipherable (outside of perhaps ultra secret projects -- then maybe those agencies should have a name generator :) ). The cute names even if based on some theme get very old and the cultural context almost always gets lost once the company/team outgrows. Also it's a much easier to refactor away a new service if lets say you find yourself adding a completely unrelated feature to a service named "accounting" or something boring,whereas if you named it "hades" or something cutesy, you don't have any indicator whether the feature has outgrown. I've found it much easier to deprecate/sunset services and systems when they're obviously named too. One exception I'd say is when nicknames just arise and it becomes obvious to call it that. It's very rare and it happens. Borg at google is perhaps a good example here. It's so all encompassing that it's obvious what it means and calling it another name like "container orchestrator" or something similar perhaps doesn't have same gravitas. I think Microsoft had something called Autopilot which is even clearer but not it can be applied to many things.
• Towaway69 4y ago
  My approach is cute or funny names based on abbreviations, e.g.: - trump - totally reversible universal manipulation protocol - Biden - booked Internet device expense network That way a cute name has a meaning. Additionally one can change the abbreviation if the purpose changes!
• nirui 4y ago
  I think "either this or that" type of thinking is unfit for the topic. A better strategy is to setup a priority: making the name descriptive should be very close to the top, and making it also cute should be somewhere down the line. Also, cute is really subjective. Personally I think "Continuous Integration/Continuous Delivery" is cute and "cli-anal-stats" is very cute, even through you might not think of it the same. The advantage of descriptive names is that it's more recognizable, you read the name, you knew what they do, and that's cute for me.
• cbeach 4y ago
  I’m at a mid size company that is currently moving away from cute names onto meaningful names. I’m glad we’re going in this direction as the onboarding process was painful, trying to piece together so many arbitrary facts, and I’m reminded of this pain every time someone joins and I have to talk them through architecture diagrams. Using meaningful names will force us to maintain microservices that honour the single responsibility principle. Scope creep is a form of tech debt, which must be repaid as opposed to being tacitly endorsed by naming services with mutability in mind.
• SideburnsOfDoom 4y ago
  Title is wrong, should be "Thank You Mario, But Princess Peach Is in Another Castle!" /s If you disagree with that, then maybe you are in favour of descriptive, not cute, names after all. I really thought that we had moved past this "cute pop culture reference naming" idea, but here it comes back again. Just no.
• Xorakios 4y ago
  When the name is public-facing rather than internal, cute is better because it's better suited for trademarking.
• rk06 4y ago
  Why not have two names? Canonical (descriptive) and a code name for referring. I am all for Descriptive names, but they tend to be long and hard for uninitiated to pronounce or remember correctly
• nzach 4y ago
  The worst is when cute meets descriptive. I've worked at a place where we had dozens of microservices, all named after random mythology. And all names must had some relevance to the actual function of the service. The shopping cart service was named Freyja[0]. The content management service was called Metis[1]. Every single service had a 'cute but descriptive' name, and it was hell. If you didn't know that tale, the names don't mean anything. And if you do know you still have to guess what the the service does. [0] - https://en.wikipedia.org/wiki/Freyja https://en.wikipedia.org/wiki/Freyja [1] - https://en.wikipedia.org/wiki/Metis_(mythology) https://en.wikipedia.org/wiki/Metis_(mythology)
  • ilyt 4y ago
    Metaphors don't qualify for cute but descriptive, there is nothing descriptive about it.
  • bryanrasmussen 4y ago
    I still don't get why Freyja would have something to do with a shopping cart?
    • nzach 4y ago
      If I remember correctly it was because she rode on a cart.
• andy_ppp 4y ago
  Why not take this to its logical conclusion and name modules, functions and variables cute names too. You need to understand the program and the code could be lying to you with its naming so why bother to name them at all. Start with Pokémon characters, atomic elements, geographical features etc. The possibilities are endless! This naming strategy can also save time when refactoring because you can change the meaning of a variable (for example) without having to rename it everywhere!
  • surement 4y ago
    just name things with single letters and when you run out you can use double letters etc. you'll be so fast at writing code a promotion is sure to follow
    • contravariant 4y ago
      Contrarian take: If your code is unreadable with single letter variable names your comments aren't clear enough. Case in point: Mathematics.
• weitzj 4y ago
  It get’a interesting when different companies decide to go down the Greek mythology pathway and the same service names pop up with different meanings in each company :) Also worth mentioning this as always humorous micrososervice video from Krazam many of you may know already: https://youtu.be/y8OnoxKotPQ https://youtu.be/y8OnoxKotPQ
• jonstewart 4y ago
  I work as a developer at a consulting company, and the consultants are constantly writing new scripts, Excel templates, and so on. Most are early career and get excited about having created something new, so they like using cute names. The practice has been to use a bird name. So my life consists of bewildering sentences about how raven is old and busted but blue throat will handle this situation, especially if used in concert with agelaius and peregrine, and run on a greyhawk. TFA is utterly wrong. A few things can perhaps stand the test of time and be worthy of a name, but use cute names sparingly. And, resist the urge to name something at all—it is far better to use umbrella terms inside an organization to avoid mass confusion by those that don’t need to have day-to-day knowledge of your software.
  • jrib 4y ago
    We use bear names. It is fun and at this point (for me) the names are second nature. But the company merged recently with a couple of other companies and the confusion about polar bears versus grizzly bears versus panda bears is pretty funny at times (and counter-productive). I try to use both the code name and the descriptive name. So now I say something like: "grizzly marshmallow roaster" instead of just "grizzly".
• beefield 4y ago
  Well, I have worked in an environment where database server names were server software version concatenated with a shortish but high entropy random alphanumeric string. I'll take cute or descriptive any day over that.
  • andy_ppp 4y ago
    Yes, some places I’ve worked named servers with four numbers separated by full stops, it was crazy!
    • quickthrower2 4y ago
      Even better if they are in the 0-255 range but different from the IP addresses they are using!
      • moffkalast 4y ago
        Satan: "I'd just like to say I'm a huge fan..."
  • deltarholamda 4y ago
    I've heard the "cattle not pets" argument for servers, but I hate that. Naming a server is like naming a boat. I've done it where everything is named after astronomers, or physicists, or even comic strip characters, but I also like it when a server is named, well, with a name. "Hey guys, Jeff is throwing errors again, need somebody to find out what Jeff's problem is."
    • tremon 4y ago
      It depends on scale. If you have 3 servers that you manage individually, you name them like pets. If you have 3,000 servers that you manage through automation, you enumerate them like cattle.
      • deltarholamda 4y ago
• Sholmesy 4y ago
  I've never disagreed with something more. > On the other hand, something that's cute will be far more memorable and much easier to say. Citation needed? How is <random-fairy-dust-word> easier to associate with "Ingest, Processing, & Storage of Thing" than <thing-etl-service>? EDIT: On closer inspection, I think this is intentional HN rage bait.
  • surement 4y ago
    > EDIT: On closer inspection, I think this is intentional HN rage bait. do flag stories like this
• Shank 4y ago
  At my company, we have an app called "rails app". It's the main app we have, and it's hosted in rails. Makes for some interesting discussions about what rails is truly capable of, what features are rails features or are rails features, etc.
• xvilka 4y ago
  Or use names of Lovecraftian deities. It better resembles the spirit of the industry.
• ChintanGhate 4y ago
  Go for boring descriptive names that create a cute acronym. Win-Win!
• quickthrower2 4y ago
  I disagree because if your machine learning service, Rudolph, has become a load balancer, you have bigger problems! You can create a new service to do the new thing! IaC might make it easier to rename stuff anyway but not everyone does that.
• throwawaaarrgh 4y ago
  As an example of the author's idea in practice, imagine a car, where every part in the car had a cute name, and every car in the world had different cute names. Now imagine being a mechanic. Or going to work for a new car company. Or just being in analytics and trying to understand how to work with the product. Or being a customer trying to understand how your new car works. A part named after its technical role/purpose shouldn't need to be renamed. If its purpose has changed, you have a different service. Without renaming it, are you talking about OLD cutename, or NEW cutename? Or NEW-NEW cutename? Major version numbers help here, for any kind of name. Sometimes names are too generic, like "web", or "auth". New services can be named something more specific to be more distinct. Things named after parts of the organization always get renamed, so always avoid that. No team names, org names, business specific monikers, etc. And the whole idea of code-as-docs is that your code is descriptive enough that you don't need to pepper tons of comments through the code to understand what it's doing. The same can be applied to architectural components like service and server names. But you know what? If you really feel that strongly about it? Go ahead and use cute names. For your service. The rest of us will be using boring names, and yours will be the odd service out, because you don't get to tell the entire team/business what to do by fiat (unless you're a horrible micromanager).
  • Aaargh20318 4y ago
    The author is not talking about the individual parts though, they are talking about entire services. So basically products or maybe large modules. To use your car analogy: It's the Ford Mustang, not the Ford goes-really-fast-as-long-as-you're-not-taking-any-corners-sporty-car
    • throwawaaarrgh 4y ago
      Read their first two paragraphs again. They're talking about individual services (and so am I). Steeringwheel-svc, Rackandpinion-svc, Shifter-svc, Engine-svc, Transmission-svc, Axle-svc, Tire-svc. Same as filetransfer-frontend-svc, filetransfer-batchloader-svc, filetransfer-batchtransform-svc, filetransfer-db, etc. (those names might still be too generic, but at least you know what I've just described)
• bmitc 4y ago
  I 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 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”.
  • michaelmior 4y ago
    > > Trouble is, names are hard to change. > No they’re not. People just aren’t determined or organized. I think this point from the article gets to the harder part. > Once you've said a name, it starts to stick in people's heads, and it slips beyond your control. Other people use the name in conversation and it ripples out through the organization. Technical modifications to change a name are one thing. Once people are stuck with using a particular name, it can be hard to change that.
• mattlondon 4y ago
  No 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 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.
  • vvillena 4y ago
    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.
    • MayeulC 4y ago
      Well, if you change the role of a named thing, change the name too. The role change is probably breaking many assumptions already. You can also keep the old name around as a stub to talk to the new one, if needed (like during a transition period where it becomes deprecated).
• bryanrasmussen 4y ago
  so are the names master and slave originally meant to be cute or descriptive, and how did that work out for everyone?
• abram 4y ago
  I read this article and was surprised it was written yesterday because I could have sworn I read it a few months ago. Turns out I was remembering a post by a different author making the same arguments, discussed on HN here: https://news.ycombinator.com/item?id=32807969 https://news.ycombinator.com/item?id=32807969
• harryvederci 4y ago
  I agree, it would be much better if the article url would be ntietz.com/puppy/cuddles-and-teddybears
• micro_charm 4y ago
  Feel like this article was intentionally written to validate Cunningham law and to promote bikeshedding. It's an almost perfect trap for that
• wellpast 4y ago
  For broad services and product lines, this is 100% correct. Change is inevitable and having a simple (cute) name allows collective semantics to float with reality as it changes. Of course for less volatile components, descriptive is useful, almost necessary. One of the most important skill sets in putting together technical systems is understanding the difference between volatile vs stable components. The problem I’ve found is that so many technical people can’t fathom change or see where change is inevitable. So they operate as if everything is stable. That’s why you see so much pushback against the idea proposed here.
• amarant 4y ago
  Surely this is satire.... Right? Right?
  • Lapsa 4y ago
    has to be
• AYBABTME 4y ago
  How about making them descriptively memorable: - shifting-priorities-routing-service - indiscrete-secrets-vault - gdrp-user-immolator - knock-knock-whos-this-authn - canihaz-authz I don't buy the "can't rename services" arguments though. It's also hard to rename variables, modules and stuff. We do it. I'll tell the PM I need to rename this function if they want to know what I'm up to. How often does a service morph so much that it needs to fundamentally change its vaguely-descriptive-name? Realistically I don't think I've even seen this happen once.
  • xeyownt 4y ago
    The advantage of making cute is that you can also make them small. I would really hate using shifting-priorities-routing-service all over the place, in particular in combination with steady-allocating-routing-service. Between cute/descriptive, long/small, it all depends on how often/where/long these names are used.
    • AYBABTME 4y ago
      You can call it by the cute name in casual speech and still guess what it does by looking at the process/deployment/artifacts name. "I'll deploy knock-knock-whos-this this afternoon" -> `kubectl apply -f knock-knock-whos-this-authn.yml`
  • Tangurena2 4y ago
    I think the "can't rename it" applies to APIs. Some of the PDF functions have COS as part of their name. The original name of Acrobat was Carousel. COS stands for Carousel Object System. The first version of Acrobat was released in 1993.
  • surement 4y ago
    > I'll tell the PM I need to rename this function if they want to know what I'm up to. Why can't more engineers do this? in my experience people rarely ever question the product team and you can see this in the products you use all the time. PMs are not robots, they do things the way that seems best given the knowledge they have of the customer and the software, but engineers have more knowledge of the software and they need to communicate it when it's relevant instead of overcomplicating features by blindly shimmying in what product is asking for.
• carlosrdrz 4y ago
  Surely there is some middle ground? Why everything has to be black or white and everyone needs to give silver bullet rules? A service that stores something can be called "catalog" and it is descriptive, short and memorable. On the other hand, a service that does too many things can be called "zeus" or "cyclops" or whatever and that's okay too. It's difficult to have memorable and short names when things do too many things, or as mentioned in the post, they might change responsibilities. Also, when you have something descriptive composed of multiple words (like "data-streaming-analyzer") people will certainly start using acronyms (DSA) and then you're back to short names than don't mean anything. There's a world where everything is not called "pikachu", "cyclops", "potter" and "tortilla", nor "main-store-red-website", "download-analytics-store-and-processing", "sells-stream-processor". Use both. They are both useful!
  • ryanjshaw 4y ago
    I feel it's helpful to distinguish between "applications" and the "services" that make up those applications. - application name: not descriptive unless you are 100% sure scope will not change over time (e.g. a specific report mandated by a regulator); exception to the rule: I actually like using initialisms because they start off descriptive but then over time people use the initialisms exclusively and its almost like you invented a non-descriptive word without the initial confusion - service names: start with a monolith that is just the application name (or suffix "Core"), only split into other services once you have a good reason, and scope is clear, and then give it a descriptive name
• Arch-TK 4y ago
  I name all my machines after a theme, unlike a major organisation I don't have the money to have dns-server-0 and dns-server-1 which ONLY host an authoritative pair of DNS servers and then web-server-0 which ONLY hosts my website etc etc. But if you can guarantee that something will continue to be one thing for ever and ever, I think maybe a descriptive name can work. It really depends on what level of analysis you're working on. Services probably shouldn't change their core purpose over-time, but business pressures may result in them changing their core purpose.
• shp0ngle 4y ago
  What’s a better name. “Epiphany” or “GNOME Web”? Everyone calls it Epiphany anyway. So yeah I agree.
• brabel 4y ago
  The argument has convinced me, even though I thought it was crazy, initially. Very good points and for many things, I think this applied very well.
• reassembled 4y ago
  What annoys me is when internal code names are used all over the place throughout the code base. Sure it might make it easier for those steeped in years of company culture to navigate the code, and provide a slightly more playful company culture, but it makes it an absolute nightmare for a beginner to find things. Furthermore, I often see companies use trademarked words for internal code names, which could lead to problems if their usage is leaked outside the company. I can’t remember what it was but I recall reading that such use of trademarks for internal code names led to legal issues for a company.
  • dctoedt 4y ago
    > I recall reading that such use of trademarks for internal code names led to legal issues for a company. Apple Macintosh, perhaps? https://www.macworld.com/article/669214/how-the-macintosh-got-its-name.html https://www.macworld.com/article/669214/how-the-macintosh-go...
• nibbleshifter 4y ago
  I've flipped between these two positions (descriptive and... not descriptive) names. I settled on nondescript and just mash two random words together when making a new project. ~90% of my actual work projects are less than 10 files of source code anyway (not counting dependencies, readme, make file, requirements.txt, etc). The vast majority are one file Python or Bash scripts.
• xcambar 4y ago
  A company I have visited had, for some obscure reason, decided that teams should have their own fun/memorable names. Almost 2 years after implementation, every new hire's first comment was: "it's impossible to navigate the org with those names, we have no idea of what each team is doing". I could live with funny+descriptive, but for all that is good, funny only just does not work.
  • tabreu 4y ago
    This. Balance is key imo.
  • grahar64 4y ago
    Yes, and we should change an entire companies culture to make a new hire onboard slightly faster /s
    • surement 4y ago
      the average tenure for software engineers at most companies is two years, so yes it's not just onboarding, a newer/more junior engineer is much more likely to misunderstand something and introduce a bug if specific context is required to understand the code
    • xcambar 4y ago
      In this occurrence, I couldn't measure the benefits of that specific element of culture. It may have been silent and powerful, I'll spare you the extra comment ;)
• jagged-chisel 4y ago
  > Names are hard to change. Brands are hard to change. Is your thing a brand for your company? Probably. You need your "cute" name (branding, differentiation, trademark) and a descriptive name. "Marmaray" tells the reader nothing. "Marmaray Tunnel Service" is more informative. Of course, once your fellow conversants become accustomed to the vocabulary, "Marmaray" is going to save time during speaking. Until then, you're just going to have to be aware that you'll need to educate folks along the way. I find it outright pretentious when I hear anyone using strings of "cute" names with no attempt at actually explaining the stack.
• deafpolygon 4y ago
  Says names should be cute. Does not offer cute name in article.
• code_runner 4y ago
  I worked for a company where everything was cute names with a particular outdoors theme. All of the conference room names had the same theme. Starting out it was impossible to navigate if we were even talking about a product or a conference room etc.
• fragmede 4y ago
  Three great unsolved problems in computer science are naming things and off by one errors.
• tabreu 4y ago
  I love this. Another issue I have with descriptive names is that wrappers and other components quickly get out of hand, then you have machine-learning-worker-wrapper-utils and conversations about this become impossible. Someone argued that cutesy name hides the responsibility; Personally, I think the effort of resisting making cutesy name do stuff it wasn't originally designed to do is well worth the ease with which you discuss these now concisely named components.
• eliasffyksen 4y ago
  I like descriptive names that fade. It provides a sort of local etymology. Maybe not good for business, but definitly provides some interesting discussions at the pub.
• jraph 4y ago
  The more I read about this topic on HN, the more I have a strong opinion that I should not have a strong opinion on this. (I'm for cute AND descriptive though) (and somewhat not against anything, unless things too generic like "Web" or "Internet Explorer" for a browser or "File manager" for a file manager)
• xtiansimon 4y ago
  Funny trifle. I too like cute names at high levels of abstraction, because descriptions or explanations shouldn’t clash with the named bits—particularly in documentation. But when a named thing doesn’t escape the code files, then it has to be descriptive. My projects take too long, and coming back to a too cute name is a PITA. The exception is I use verb+cute name for command line script names. Naming is hard, but also fun.
  • tremon 4y ago
    My thoughts exactly. Cute names are identities: you apply them to things that are unique and where the purpose is malleable. Functional names are descriptions: they capture the thing's purpose, not its identity.
  • xtiansimon 4y ago
    Curiously, this week I was doing some project in Python where a visual plot was necessary. Now here’s a sphere where naming actually sux. I say this because there is a rich history of terms around visuals. When your project includes these other ontologies, it’s not so fun.
• dudeinjapan 4y ago
  So... why did the author give this blog post a descriptive title? Wouldn't a better title be "Fluffy Bunny"?
• fedeb95 4y ago
  yes, piling up dust under the carpet could have a cute name. You don't want to pile it in the first place though
• btbuildem 4y ago
  This is one of the hardest problems in software development, and with good reason. Naming things is how we get a handle on them, how we mark our understanding of them. It's a pivotal issue, in how it attaches our brain-maps to the problems we tackle. How many times, as a developer, have you paused and pondered what to name a new entity? I often find the difficulty of naming a thing is directly proportional to my depth of comprehension of that thing, what it does, and the context it lives in. With that in mind, I see naming-things-for-what-they-are as one winning strategy. Quoting from OP: > The problem comes in when there's a mismatch between responsibilities and names. Names are a way of expressing identity, while responsibilities are ephemeral: Your friend Sam is still Sam, even if Sam gets new responsibilities and sheds old ones. I find this a bit misleading, since Sam is a person with agency and a unique personality, and the things we name are, well, things, with specific purposes and raisons-d'etre. But! At the same time, OP identifies a key characteristic of things-that-persist -- scope creeps, features are added, responsibilities evolve. Naming a server "Sysyphus" may seem cheeky at first, but I'd argue that it's a better name than "Load Processing Server 2". We tend to antropomorphize things, that's one, but also - things happen over time, notable events, that create a timeline of stories which in turn build up into the coherent base of knowledge / familiarity / wisdom that ties teams together. Using "humanized" or "personalized" names pays off here, they help to glue these stories together and contribute to the institutional memory that builds up over time. In the end, I think both approaches are valid and have their place, we just have to use our judgement as to when to use which.
  • surement 4y ago
    > This is one of the hardest problems in software development and that is one of the worst fallacies in software development naming things is not hard, people regularly give things terrible abstract names because they act like it'll never be possible to rename it and then add a 3-4 word comment above describing what it does if they just named it what the comment says then they'd have a fine name
• thenerdhead 4y ago
  I work somewhere where naming is notoriously bad both cute and descriptive. If I could wave a magic wand about naming, I would wish that people put less time into thinking about naming. You get better names that way. A simple exercise in improv could even be applied. What's the first thing that comes to the top of your mind when you think of "X"? If majority of people say the same thing, you run with it because that's the most obvious one. Choose the obvious one.
  • hawski 4y ago
    I'm afraid it would be tmp and tmp2.
• zelphirkalt 4y ago
  The purpose of naming things is to convey their meaning and character. By giving a non-descriptive name, one loses that potential. Please do not use cute names, unless there is really no good name to pick (like ad-hoc created docker container names, when --name is not specified). Give me information through means of naming things properly.
• tauwauwau 4y ago
  I think we are mixing two different scopes in the the discussion here. If you are naming a company or a product that will be offered to clients, name it something unique that'll appear in searches. However, if you're writing a piece of software that's not going to go outside the company, having descriptive name is the way to go. You can even name your products with generic descriptive names, if your company's name is unique enough, then that'll act as a namespace for product with generic names. Think of packages in Java, C#, we don't debate about that we have to use a cute name for a X.java or X.CS, because that problem has already been solved by namespaces. Product name Excel and Office works for Microsoft because that "Microsoft" acts as namespace and "Microsoft Office" and "Microsoft Excel" are unique enough to be fully qualified names. The ntietz entry is talking about using cute names for internal services, which is very bad idea. Please enjoy https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ
  • m_mueller 4y ago
    IMO there is a middle ground: larger & long living services that are internal only, and you have 1-2 handful of them. At my current employer I've started with greek gods whose background is related with the service we're building. E.g. Apollo = god of truth = data warehouse; Hermes = messenger god = messaging service for reporting, etc. It's quite successful in that these names are more quickly adopted and recognized by internal business users, compared to giving it a boring functional name. It also clearly outlines that they are part of a wider concept (new tech stack = greek gods, legacy marked for decommissioning = mostly everything else they hear).
  • leokennis 4y ago
    The issue is, if you create an internal tool that allows you to order printer paper for your departments printer you might name it "PaperSupplier": https://papersupplier.acme.com https://papersupplier.acme.com. If it doesn't work, just send a mail to papersupplier@acme.com! And it works so well, the company now also wants employees to order staples and hole punchers through it. What do you do now? Are you going to rename the tool, change the address, change the e-mail? Or is your company now going to have you order your staples through "https://papersupplier.acme.com https://papersupplier.acme.com"? We all know it's the second. My strategy would be to go for very generic names: even though it (initially) only allows you to order paper, name it "Internal Supply Portal" or something.
• kpz6 4y ago
  > I don't want my services or projects to sound like a law firm ("Ingest, Processing, & Storage LLP"). That would actually be a fun name.
• andix 4y ago
  So how do you call your services? Harry, Ron, Hermione and Voldemort?
• sixstringtheory 4y ago
  The renaming point is actually the great point in this article IMO. But this just tells me that languages, platforms, frameworks and editors need to improve so that renaming things is easier. Or that people need to learn how to use grep/sed better (ETA: and use monorepos)… But this: > they're no fun > it won't be fun is the bane of my existence as someone who tries to get shit done. If this is the lens through which you view software development, and I have to work with you at my job, I literally hate you.
• thedorkknight 4y ago
  So basically descriptive names might eventually become non-descriptive, or loosely connected. "Cute" names are ALWAYS non-descriptive or loosely connected though. So at worst, a descriptive name eventually becomes as bad as a cutesy name. Given my experience being onboarded onto legacy code, and bringing others up to speed on my team's code, I'd much rather have names help coders understand the systems 9/10 times as opposed to 0/10 times I'm not sure I see the point
  • toomanyrichies 4y ago
    > 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 R&D, just because something is named DescriptiveThingThatDoesXYZ, doesn't mean it actually does XYZ. So now they have to verify what a given class or method does every time. Which means you have the same problem that cutesy names cause (the non-trivial effort of looking stuff up) plus the lack of trust that is now engendered in your engineering org. To be clear, I think I still fall more towards the "use descriptive names" camp. As another commenter has said, by making it easier to add responsibilities to a certain class or service, the "use cute names" camp promotes the creation of God objects that take on too many responsibilities. But man I hate it when a class's name is actively misleading.
    • salawat 4y ago
      >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. My God... You don't mean to tell me you actually object to having to read code and figuring out what it does in the grand scheme of things? I swear, everyone wants to be a writer, but no one wants to read and understand.
      • grahar64 4y ago
• stiiv 4y ago
  > The problem comes in when there's a mismatch between responsibilities and names. Names are a way of expressing identity, while responsibilities are ephemeral: Your friend Sam is still Sam, even if Sam gets new responsibilities and sheds old ones. This analogy falls short. Services aren't like people -- their names aren't bound to their origination, but they can be bound to their function. That's a choice for a developer to make. But how common are are actual mismatches between service responsibilities and names, really? What kinds of systems or features or teams do name/function mismatches commonly track? Speaking strictly for myself: I've worked on SOAs and microservices (mostly for .NET) since 2005 for half a dozen companies on both new and existing systems, and I can't recall _any_ such mismatches.
• nightowl_games 4y ago
  I agree. Right now I'm working on a service called simply 'backend'. We are adding some environment variables to it, and I'd like to prefix them with something relatively unique. BACKEND_DATABASE_ADDRESS is simply not unique enough to pollute the environment with. I know this example isnt perfect (and no were not even writing these env variables to the user's shell), but it demonstrates the lack of identity.
• suyash 4y ago
  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.
• whoisthemachine 4y ago
  > 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.
  • lioeters 4y ago
    ..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/backyard needs. It will also be a subscription-based business model, always needs to be connected to the Internet, and have machine learning for full self-driving.
    • whoisthemachine 4y ago
      We call these tractors, although the adapter is usually on the rear! And I think they are gaining some AI.
• Waterluvian 4y ago
  Help me, for I am socially malnourished. This is a joke, right?
• eckesicle 4y ago
  I'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.
• desio 4y ago
  Wish I read this before I named gonna my dog "Noise Maker".
• djmips 4y ago
  I worked at a place where they named all of the systems and tools with puerile gross words. They thought it was cute. I thought it was a chore and also not easy to keep straight.
• the_af 4y ago
  It seems the author correctly points out some problems with descriptive names, but then advocates for "fun" names without explaining how they deal with the problems. So the solution is that they are "more fun" and give up on solving the problems whatsoever? I've dealt with cute names in past jobs. Because they are meaningless ("Thoth"? I think that's an Egyptian god, but what does it do?) I've spent months confused. And when I didn't deal with them, I forgot what they did, especially since in the microservices world there's so many of them. I'd rather have a slightly outdated but descriptive name than a completely meaningless "cute" name.
• jfoster 4y ago
  I can't prove anything, but I have a feeling that this article was intentionally written to be annoyingly wrong in order to generate engagement.
• hcarvalhoalves 4y ago
  Nobody today would believe naming classes after greek gods or anime is a good idea, but for some reason it's okay for (micro)services. I've worked at places that do this, I think it's a bad idea. Not having descriptive names turns architecture discussions into bikeshedding ("I think we should create a new service named Pikachu instead of extending the scope of the Naturo service").
• jacknews 4y ago
  LOL, is this sarcasm? Perhaps we should copy science and maths and name services after their developers: chet-obagdu-braithwaite server peyton-garcia endpoint murata-checkov service somerstein API etc. LOL.
• secondcoming 4y ago
  Giving things cutesy names is hardly inclusive behaviour, especially for those who don't speak English as a first language.
• once_inc 4y ago
  Leave cutesy and or funny names for instances of software, not the software itself. You can have a complicated java program with dozens of classes and high levels of abstraction all named with the usual 'boring' names, and run an instance of that class an have it called r2d2, ultron, or "An Eridean named Rocky". That antropomorphizes the program, which leads to higher acceptance and easier internal communications.
• mnw21cam 4y ago
  TBH, I don't care if your names are cute or descriptive, but for the love of God, can they please be Google-unique? I don't want to search for a particular software tool and end up getting loads of results about hamsters.
• grahar64 4y ago
  I agree with this 100% and have seen this play out many times. At one company we named the service “Harry” after one of the employees kid’s. Worked well, and I will fight for such names at any company I work at.
• arichard123 4y ago
  Are we short on good words to describe the moving parts of our systems? We use so many synonyms for "thing" that then get overloaded. Do we not just need to invent some new words with specific and useful meanings? I'm not sure where the different lines would be drawn. Perhaps thinking about a specific program might be helpful. This can't be new thinking can it. What naming conventions do people use that aren't obvious but are useful?
  • grahar64 4y ago
    The word “transaction” is so overloaded it would be pointless to use in a system. At a previous company we had to have a glossary of words that you could use instead just so the documentation made sense.
• trimethylpurine 4y ago
  It seems to me that you have bigger problems than nomenclature. Do you add comments to your code? That's because you're part of a team. When you add function it should go in a separate package. Again, you're part of a team.
• __MatrixMan__ 4y ago
  I agree with this. Where I work, one team has given descriptive names to everything and several other teams have then shortened them inconsistently. So it's tribal knowledge that "cloud" and "gen2" are the same thing, and software/platform/gen1 are almost the same thing, but configured differently. If we had called them Frank and Susan, we'd know what each other means.
  • surement 4y ago
    if your solution to overly generic names is names that are meaningless without context, you probably have bigger problems
• stared 4y ago
  Let's go further: Function (and class) names should be cute, not descriptive. It is impossible to predict how these evolve and change their names.
  • devnullbrain 4y ago
    The mirror to this argument is that company names should also be descriptive. Goodbye Amazon, hello OnlineBookStore.
    • stared 4y ago
      There is plenty of successful companies with descriptive names. Facebook, IBM, BMW (Bayerische Motoren Werke), Grammarly, Duolingo, OpenAI, etc, etc. Personally, I prefer this approach. When a company gets big, it does not matter. If something is small, at least I get a f---ing clue what it does (and it is easier to memorize).
      • devnullbrain 4y ago
        I'll give you two of those.
• jxf 4y ago
  > I don't want to be the one to advocate for delaying features so we can rename broadcast-service to broadcast-and-new-responsibility-service. That's going to be an unpleasant conversation with your product manager, for good reason: Because this never should have happened, and it's a waste of time to change the name. I couldn't disagree more. This is exactly why you would want the name to be descriptive. If the thing that's supposed to be a notifications service suddenly also starts processing payroll, that's absolutely a friction point that should give people pause.
  • sesteel 4y ago
    Could not agree more. Naming things for what they do encourages other behaviors like deprecation strategies and extension strategies that are non-disruptive to others. It makes people's lives easier if your work follows a level of rigor for naming. Products and companies can do many things under a single name, APIs should try to do the fewest number of things under a given name while fitting the concept as closely as possible.
  • deleted 4y ago
    [deleted]
• foxyv 4y ago
  I usually do both. I'll have an easy to remember Code name followed by a descriptive name. This is to disambiguate the 700th TranslatingProxyLayer project. For example: ReliantRobin-DatabaseCleaner Now when I search for it in a wiki or documentation I can find it easily, but people still know what the heck it is.
• rhacker 4y ago
  > Your friend Sam is still Sam, even if Sam gets new responsibilities and sheds old ones. But that's just your perspective. At HogCorp Sam is the Senior Data Engineer. People that need data adjustments probably go to the Senior Data Engineer, whether that is Sam or not. If Sam becomes VP of Accounts and is no longer the Senior Data Engineer, people won't stop going to the Senior Data Engineer, but it won't be Sam anymore.
  • joelthelion 4y ago
    Mmm, you'd be surprised. If Sam becomes VP of Accounts, people will still try to go to him for their data engineering needs, unless he tells them off...
• kmac_ 4y ago
  Of course everybody knows what Galactus does!
• fckgnad 4y ago
  I disagree. But cute is better than a fucking acronym. Never never never use acronyms or one letter variable names.
• gloosx 4y ago
  My favourite: status: Enum<0,1,2,3,4,5,6,7,8,9> // 0-kitties, 1-puppies, rest in Confluence
• eightturn 4y ago
  i guess I'll just let VidaliaOnions.com expire then ... :/
• themoonisachees 4y ago
  As a sysadmin who deals with several clients with different naming conventions wrt server hostnames, i feel like both schools annoy me; for example one of our clients has FRPRTFSQL02, where fr is france, pr is production, tf is the app this server relates to, sql is the type of service this hosts, and 02 is sequential, so for an sql server this means it's most likely a ro replica. On the other hand, another client names their servers just "montana", "barcelone" or "morroco" with no relation to the geographic aspect of the name. In both cases, and maybe this is just because i work and exist in this wierd liminal space where i care about the server but not what's on it (if i end up caring what's on it, i find out what i care about by looking at logs etc, not the name) so both ends of the spectrum tell me absolutely nothing about the machine and it's just an annoyance to remember them. I find cute names easier to remember and tell my coworkers about, for what that's worth. On my own infra, i name my servers with simple descriptive names, like "matrix" is hosting matrix and "play" is hosting game servers, but i don't have the infrastructure for that to be a problem (ie i do not have 2 copies of anything running) so i can afford to do it, but i know it's not a good solution.
• xorcist 4y ago
  The right question to ask is how and when hostnames are serialized to disk and how you need to interact with them. The most common in my experience are for logging, metrics, backups and monitoring. So those interactions are important use cases to consider. In my opinion a good hostname, given an enterprise setting and in order of importance, should reflect 1) if the host is production, a staging area, or someone's toy, and 2) which group or team has responsibility or it. If relevant, also 3) what type of server or role it is. Should you find some sort of data dump or log that contains a hostname, it should be immediately obvious how sensitive it can be and with whom to speak. This basic requirement mostly rules out "cute-only" names.
• twawaaay 4y ago
  I think names should first of all be reliable. What I mean by reliable? * It does not change either in time or space -- you have to come up with a good name right from the start and then you are not allowed to change it. The same thing has to be named the same way throughout the system and ideally through multiple connected systems. * It must not mislead -- the name does not have to be super descriptive (although it is a desired property) but it cannot cause you to think the thing does something it doesn't do. * It must be unique -- the same name cannot be used for different similar or dissimilar things.
  • kevincox 4y ago
    Your list is very similar to mine: https://kevincox.ca/2021/03/23/good-names/ https://kevincox.ca/2021/03/23/good-names/ I agree. The uniqueness and stability of a name is key. Then making is not mislead is good. Then being descriptive is nice. I think the article is hitting on descriptive names can become misleading over time. People will think that a descriptive name is helpful, even if it was poorly chosen or is no longer accurate.
• rhacker 4y ago
  While I don't agree with the author AT ALL. I think products need two names: a marketing name and a code name. I was at a company that kept renaming the marketing name. And for some reason I couldn't get the programmers to stop spending weeks redoing packages: com.companyname.integrationhub to com.companyname.superconnector. I kept trying to tell people that the marketing name is going to change all the time and that the package we put it under should be very different from the marketing name - on purpose, so that we don't need to repackage it every 2 weeks. Call it com.companyname.dataintegrator. The marketing name of the data integrator can change all day long and its package must remain dataintegrator.
  • kevincox 4y ago
    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 where a "codename" is a much better match. Having two names is generally only a tiny bit confusing. I have also yet to see a codebase rename that completes before the product name changes again. You always just end up with a confusing slew of N names in the codebase if you try to rename.
    • pphysch 4y ago
      It seems that most business objects should have all of the following: 1) A memory-friendly, indexed, unique, immutable ID (e.g. BIGINT or GUID). 2) A human-friendly unique immutable codename/slug. 3) A human-friendly mutable marketing/display name. 1 & 2 could be combined in some cases
    • dlivingston 4y ago
      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 https://developer.apple.com/documentation/appkit/nsview
• AlanSE 4y ago
  This reminds me (from a long time ago) of seeing IT department stick names of jungle animals on computers so they can be recognized on the network. These days, there are many cases where _instances_ of something are given random "cute" names. A particular server will have a suitable-for-work but fun name slapped on, like "grumpy goat". Hover, I can't imagine _classes_ of something following that kind of naming convention. This post seems to be more about _queue_ names or _service_ names. Software DOES intentionally use cute and random names for big-ticket items (see "git"). It would be confusing to apply this practice to more minor software, because it would be too many to remember. If I have a service as a part of an app that consumes data from a redis queue and sends it to a log collector, a fully descriptive name is distasteful, but I wouldn't want to name it "anteater" because even if my mental picture is vivid, other people will... not get it. I'd call it "log-passer" or something.
• Hani1337 4y ago
  Why not both? Do it like counterstrike maps with their gamemode prefix de_ cs_ kz_ surf_ host_dandelion01, client_pollen01, merger_fusion, compiler_compost_v1, etc
• cosinetau 4y ago
  Got a cute name for this: bikeshedding.
• discordianfish 4y ago
  (Micro)service names should be descriptive and stick to doing what they are named after. If you need to change the scope, it's an change to the overall architecture and changing the name and good way to communicate that. If a employee reads the name they know what its suppose to do. Company and product names (including e.g open source projects) are different. You want to be able to change your scope depending on customer demand without having to rebrand.
• erikpukinskis 4y ago
  Lots of people pointing out how bad this is for new hires, but it’s not just a hurdle for new hires to get over… in a lot of cases people will just _never get over the hurdle_. The discussions outside their team will just be a bunch of gobbledygook that they tune out. And years down the line you end up with a really Balkanized engineering culture. Where you know what happens in Zeus, but you have basically blocked out Persephone, Ulysses, and Palmyra because they are another team’s responsibility. Maybe that’s actually a good thing for some organizations, I know many CTOs spend most of their time trying to make cleaner separations between teams. But if you want a culture where people understand and evolve the larger architecture from time to time, cute names are going to make that less likely.
• kodah 4y ago
  > A well-factored service will generally have a tight set of responsibilities which make sense together, and this makes a descriptive name very appealing. Your service which started with a nice, tidy set of responsibilities may start to shift over time. And then you're faced with a choice: keep the old descriptive-but-now-wrong name, or put in all the effort to change it. I had this happen recently. We wrote an application with two major components: one that processes events and repackages them as generic events and a component that receives those events and schedules work. We work in a compliance heavy environment so the architecture often reflects a separation of concerns given the information being processed. The scheduler became pretty popular for people to plug into, even if they didn't use our other component. The scheduler eventually left the nest of our small, purpose-built program and became general infrastructure. It's now the "SecureScheduler", though on our component diagrams it simply goes by "scheduler". My lesson learned was that if you properly separate an application out, the component names can become independent software in the service registry over time if they need to. The scheduler is pretty strictly scoped, so it'll never start doing new zaney things. It simply schedules work in a controlled environment. These arguments over cute and functional names, I think, are a byproduct of a couple failures: - Properly naming and confining components role within a single service. Our scheduler was generic enough to operate on its own, but it's role within our architecture was pretty confined. It's main optimization compared to other software like it was the inbound communication and authentication flows that made it easy to securely plug into. - Lack of organization and vision at the service registry level. The scheduler didn't need a vastly different name, because it's purpose didn't really change. It did one thing and it did that one thing exceedingly well. There was a hole in the wider service registry that it could fill. As a result it was elevated to its own program in the service registry with its own deployment schedule.
• jkingsbery 4y ago
  > The world is boring enough as is. Let's add more whimsy and cuteness through our service and project names. This is a recipe for creating a wholly impenetrable language about your services. Which is easier for an outsider to understand: "I updated the code for how Batman writes to Goliath in Cair Paravel" "I updated the code for how the backend services write to the customer database in the billing application." > I don't want to be the one to advocate for delaying features so we can rename broadcast-service to broadcast-and-new-responsibility-service. That's going to be an unpleasant conversation with your product manager, for good reason: Because this never should have happened, and it's a waste of time to change the name. What seems to happen more often at the particular Large Company I work for is that not just responsibilities change, but fundamental assumptions underlying the architecture of a system change every few years. So rather than renaming a service, often a new system is put in place that reflects these new assumptions, and this new system will have a new name. The migration then isn't about the new name, it's about the new system, along with the new APIs and model of operation that comes with it. Yes, there are lots of examples of billing systems written 40 years ago in COBOL, but most software systems have a lifecycle on the order of 3-5 years.
• erikpukinskis 4y ago
  There’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 went on which box, in order to maximize performance. But these boxes weren’t services themselves, they were just the machine some set of services happened to run on. So we gave them cute names because the hardware was largely meaningless. They had no inherent purpose, so we named them Athena, Zeus, etc so we had something to remember. These names were largely not used for the services. Maybe you did have your FTP service on Athena, and maybe that was the only service on there. You still served it from ftp.techdazzle.com or whatever. I feel like people just ported this concept forward into the microservices realm because it’s fun, even though it doesn’t really make as much sense in a cloud environment.
  • nix0n 4y ago
    I agree that this makes sense for boxes. > we named them Athena, Zeus, etc The bonus of this kind of theming is that if someone mentions a Greek god you know they probably mean a box. One reason this makes more sense for boxes, is that a box will have features and responsibilities taken away more than a program or service will. If a service is named according to what it originally did, even though it took on additional responsibilities, that's fine.
  • bfung 4y ago
    Even more fundamental, if you had multiple computers and needed to network them up, they required a name to be referenced by. Computers on the same network ended up with names from a common theme.
  • plank 4y ago
    Ah, memories. Remember the time a new set of boxes came, and my and a collegue came up with a bunch of names. Being a physics department, the new names had to fit in the existing name convention with names like Gauss and Planck. And yes, used that to get the latter one placed on my desk (new shiny powerpc with colour screen!) instead of an old Atari;-)
• trynewideas 4y ago
  There's a decent middle ground where the cute name is also descriptive, even if it's indirectly so. For instance, Grafana's stack is Logs Graphs Tracing Metrics so their services are Loki Grafana Tempo Mimir which also spells "LGTM". Of course, then they shipped "Phlare" because apparently they couldn't find a cute name for Profiling?
• feoren 4y ago
  Early chemists gave cutesy names to chemicals, like "vitriol", "salt", and "cholesterol". Today we know the proper descriptive names for these substances, of course. Vitriol's correct name is "sulfuric acid". Salt's correct name is "sodium chloride" Cholesterol's correct name is "(1R,3aS,3bS,7S,9aR,9bS,11aR)-9a,11a-Dimethyl-1-[(2R)-6-methylheptan-2-yl]-2,3,3a,3b,4,6,7,8,9,9a,9b,10,11,11a-tetradecahydro-1H-cyclopenta[a]phenanthren-7-ol". That's not a name! It's a serialization of a molecular structure! See, the problem is that what's "descriptive" is opinionated, and a hot topic for bikeshedding. It's like the argument between natural and artificial primary keys. If you go with natural primary keys, expect managers to bikeshed exactly what's in there and how it should be encoded. They'll change all the time. Your "name" turns into an encoding of the object itself. If you call your computer "OaklandDev19InTheBasement" then what happens if you move? What happens if you get more than 100 dev computers in the Oakland basement? How many arguments are you going to have about whether it's the proper place to put some service that may not be "devvy" enough? Some people are hitting this, but most of these can be broken into different functions: Identity: always meaningless, always. Finding a service: if this is hard, you need a directory. You need this anyway, even with descriptive names. If you need a directory, can you automate it?
  • shkkmo 4y ago
    Of the three you mention, only "cholesterol" was actually named by an early chemist [0]. "Oil of vitriol" was first mentioned by an alchemist almost 1000 years ago but the term "vitriol" already existed to refer to some metal sulfates. "Salt" is much much older. [0] https://en.wikipedia.org/wiki/Michel_Eug%C3%A8ne_Chevreul https://en.wikipedia.org/wiki/Michel_Eug%C3%A8ne_Chevreul
    • feoren 4y ago
      > first mentioned by an alchemist I was really hoping we'd all be mature enough to not have this petty argument over when people studying the properties of chemicals stopped being called "alchemists" and started being called "chemists". What year was that, exactly? Exactly. I need an exact year, so I don't make this "mistake" again, please. Because otherwise, I think "early chemists" is a perfectly accurate description of early humans studying the properties of chemicals.
• daviesgeek 4y ago
  I couldn’t disagree more for service and infrastructure names. > And I think this applies more broadly to projects and companies, too. Customer facing names are fine, they should contain a bit of whimsy and cuteness. Obviously if you ship “payment-processor-gateway-v2” to the customer, that’s not a great name for a company, product, or feature. Projects also make sense (mostly), though they suffer from some of the same issues I’m about to outline. However, for internal names like for services, adding cuteness is a horrible idea. > A well-factored service will generally have a tight set of responsibilities which make sense together, and this makes a descriptive name very appealing. Descriptive names should help box in the scope of the service. If the payment processing service is also doing AI processing on user avatars, you might want to think about breaking that out into a separate service. With cute names, scope can grow infinitely because there’s no inherent description attached to the name. You may have “Athena” doing one thing but as things progress and the company/software grows, it’ll be taking on 17 other responsibilities. Instead if it’s named “backend” or “payment processor”, it’s clear in the name what it is and the scope of the project or service. Then there’s the problem of an engineer’s mental overhead. Newcomers have to learn what all the cute whimsical names mean. You have to keep an internal dictionary and someone has to make sure it stays up to date. (Spoiler: It won’t ever be up to date.) I could have filled at least two pages with all the acronyms and whimsical names from one of my old jobs and it was always an ever changing landscape. If a service is named succinctly and clearly, the engineer doesn’t ever have to think about what that particular service is or does. I understand there’s going to be some edge cases where the name doesn’t cover everything, but that’s certainly better than the case where the name doesn’t cover any of the description of the service. > It's impossible to predict with certainty how your software's requirements will evolve over time. Then within the scope of the new requirements, changing the service’s name should be inherent in the discussion. IMO, this is a sign of some bad engineering processes. One shouldn’t be worrying about names in the future if you’ve named something correctly for the current scope. If it changes, address it then. Most modern languages will let you easily refactor a name. By those standards, you shouldn’t build the software, since it might change over time and we don’t want to make assumptions about whether we’ll still be using Mongo or if MYSQL makes a comeback. We can’t make those decisions because we can’t predict with certainty…you see the trap you can easily so easily fall into? One thing that’s also a huge challenge is pronunciation. Someone will pronounce one of those cute names in a way that no one else has heard, it’ll take a minute to sort out, and, while it did get sorted, it took some time. Multiply that out over weeks, months, and years for every engineer and it can get costly. I understand that descriptive names can also be mispronounced, but since they’re common (to our industry), it’s easier to sort out. I definitely do understand the sentiment behind adding some fun. I’m not here to kill the fun atmosphere of a new startup who wants to be cute about their names, but I’ve seen it play out very poorly over a long time when the company/projects/services/team grows and it’s not pretty. Stick with descriptive names. You and everyone else will remember them easier and you’ll save time, giving you the time to go have some fun and grab a couple drinks with coworkers. (I also published this here: https://memos.daviesgeek.com/m/4 https://memos.daviesgeek.com/m/4 for a little better formatting and to keep this comment around for myself)
• furyofantares 4y ago
  I kinda wanted to agree with the author because of the number of times I've encountered and X-Yer that's neither X nor Y anymore. But honestly even in those cases it's still usually somewhat informative despite the argument that it's misleading. It's still got some essence to it, and having a clue about the history is also often useful. And it's frequently abbreviated XanYat or some such, or initialized the XY, which is just treated as any old name anyway and not a description. It's not cute or fun, and maybe less memorable (not sure about that, a single cute name is memorable but an ocean of them sounds confusing).
• kerkeslager 4y ago
  It sounds like this idea makes some sense in the context of having made a large number of mistakes already, but the real answer is, don't let it get that bad. The author strikes me as having worked only at companies that are so dysfunctional that they have never seen what a functioning team looks like. It starts going downhill here: > Trouble is, names are hard to change. Uh, why? They shouldn't be. It should be a find/replace on text, with tests to catch any issues. The essay later goes on to talk about people using the name... but that doesn't matter, because the code is the self-checking source of truth. Additionally, name changes should be rare if you did your job right the first time. > A well-factored service will generally have a tight set of responsibilities which make sense together, and this makes a descriptive name very appealing. No. Wrong. A well-factored service has ONE responsibility. Period. Not "responsibilities", "responsibility". This is what I mean when I say that a name change should be rare if you did your job right the first time. If a service has multiple responsibilities, you don't need to change the name, because you aren't adding or removing responsibilities. If you no longer need what the service does, the service can stop existing. And if you need something new, you create a new service. And yes, sometimes performance means that you want to chunk stuff together, and strictly passing every different task over the network bus will cause your application to grind to a halt. That's more a criticism of the weird assumption that passing things over the network is necessary for encapsulation than of the single-responsibility principle, however. If your services are tightly coupled to separate network requests, you're going to experience pain no matter what you do. One of the first things a microservices architecture should do is abstract away the network so that from the caller's perspective, they don't know whether calling a service is making a network request or calling a library. > I don't want to be the one to advocate for delaying features so we can rename broadcast-service to broadcast-and-new-responsibility-service. That's going to be an unpleasant conversation with your product manager, for good reason: Because this never should have happened, and it's a waste of time to change the name. Agreed, because a) broadcast-service is a pretty vague name and b) new-responsibility should be its own new-responsibility-service.
• throw__away7391 4y ago
  If you're going to do this, why not also do it for classes, function, and variables? The the reasons you wouldn't do that are also reasons you shouldn't do it for services. A product might have a code and/or marketing name, but that's a different story. You shouldn't give cute names to services or other internal components pieces of products. Every time this comes up I remember that KRAZAM Microservices video, "because Bingo knows everyone's name-o". (https://youtu.be/y8OnoxKotPQ https://youtu.be/y8OnoxKotPQ) A random aside, definitely the very worst name you can give any product is "Atlas". I once worked on a product called "Atlas" that also used a library and an unrelated external API also called "Atlas".
  • jakelazaroff 4y ago
    > If you're going to do this, why not also do it for classes, function, and variables? Because those are easy to change. Service names inevitably get strewn across who knows how many other services and pieces of infrastructure.
    • throw__away7391 4y ago
      It sounds like your deployment and provisioning infrastructure is sub-par. Why would you shove unrelated functionality into the same service? Especially to the point where you can't even choose a descriptive name for said service.
      • mlyle 4y ago
        > Why would you shove unrelated functionality into the same service? Because you notice that Broadcast-Service happens to already know some other important stuff about all the enregistered clients. And perhaps answering queries about that or naming ends up becoming its most important job... even though it was originally just a simple broadcast service. Then, later, you end up not even using the broadcast functionality. Code drifts and changes. Top level names are more likely to be lies than variable or function names, because the latter are easy to change.
• trynewideas 4y ago
  I worked in a non-engineering role at a place that used cutesy names for almost everything: meeting rooms, engineering teams, internal tools and libraries, events. Nothing was descriptive, and even just fundamental roles and responsibilities were institutional knowledge. (They were "documented", but nobody was responsible for updating the docs when people left/moved/were added.) So when a customer complaint about messaging came across my desk, I'd first have to figure out which team to go to: Ice Cream, Teddy Bear, Jetski, or Pineapple. What parts of the product does Ice Cream work on? Do they work on the messaging protocol? Or was it the app server? Oh, didn't you hear, Jetski took on the app server last month and this week they're spinning off the messaging protocol into a new team, Applejack. Now Ice Cream's only responsible for user authentication. Okay! Cool, so who's in Applejack? The Software Mage for the BrokenLighthouse library, which implements the messaging protocol? No, actually it's the Product Master for BrokenLighthouse's replacement, WorkingSignal. BrokenLighthouse maintenance is still with Ice Cream. Okay! So is the Software Mage for BrokenLighthouse still on Ice Cream, like the directory (sorry, the Cast of Characters) says? No, they transferred to Jetski with the app server, sorry, I mean AppleBucket team. Okay! I'll just join #jetski... wait, it doesn't exist anymore. Oh, right! Now that they have AppleBucket they renamed to Appleski. Okay! I'll just join #appleski. (Damn it, Slack, don't autocomplete it to #applejack or #applebucket-feedback.) "Hey, I've got a support ticket for a messaging protocol issue, can someone help?" > Sure, we're meeting in Batman on that right now! Come join us! Okay! Where's Batman? The office has two floors, Cartoons and Comics, and each is divided into four themed quadrants, and each room is named after someone in one of those quadrants. So Cartoons is split into Adult Swim, Looney Tunes, Simpsons, and Disney, and Comics is split into DC, Marvel, Dark Horse, and Newspaper. Counterintuitively, I loved watching Batman:TAS as a kid before I knew it was a comic book, so I always wind up wandering around WB looking for Batman. "Where's Batman?" Oh, Batman's in DC, upstairs. Okay! I enter Batman and find Appleski talking about BrokenLighthouse. "Hey! Is this where I can ask a customer question about the messaging protocol?" Blank stares. "Sorry. Is this where I can ask about this BrokenLighthouse error message that just says 'AppleBucket is refusing LightBeams from BrokenLighthouse due to a misconfigured PineappleSkin'?" > Oh sure! That's just the message protocol saying there's a syntax error in the config YAML. The v2 protocol will switch to JSON and provide more detailed feedback.
• dctoedt 4y ago
  When U.S. law applies, trademark lawyers urge companies to find "suggestive" names — requiring insight to realize "ah, that's what this is!" — as the "sweet spot" to get the most bang for the buck in marketing while still being legally-protectable. (Examples: Coppertone for suntan lotion; Greyhound for bus-transportation services; Energizer for batteries.) "Merely descriptive" marks can't be protected legally without proof that they've acquired "secondary meaning," e.g., through widespread advertising, going viral, etc. "Coined" or "fanciful" marks such as Reebok and Kodak, and "arbitrary" marks such as Lotus for software, are protectable, but they don't do much good in advertising, at least not initially, because customers don't know what product or service is. Self-cite: https://www.oncontracts.com/startup-law/#Trademarks_look_for_a_8220suggestive8221_one https://www.oncontracts.com/startup-law/#Trademarks_look_for... Usual disclaimer: I'm a lawyer but not your lawyer.
• atom_arranger 4y ago
  Could not disagree more.
• ryanmcbride 4y ago
  Last company I'm worked for named all their services after Toy Story characters and no one knew what anything did. "So Woody talks to Buzz that lives on the client's server and then pushes the data to Pizza Planet where Sarge queues it up to Bopeep". I hated it
• cryptonector 4y ago
  Names of products should be memorable, and probably cute. Names of technical items (e.g., function names) should be descriptive.
• anchochilis 4y ago
  I think the author has a point here. In an ideal world, we would of course spin up a new microservice every time a PR in the foobar-widget-generator service begins to deviate from generating foobar widgets. In practice, we make delivery tradeoffs all the time. It's not at all uncommon for service scope to creep while a new, urgent feature is being experimented with. And launching a new service is never, ever going to be as cheap as updating an existing, well-maintained one. My own hard-line requirement when it comes to naming services is that they should be a single word with some relationship to the service's purpose. Ideally a common English word, but proper nouns are permitted if they improve clarity. Brevity must ALWAYS take precedence over clarity. There's only so much you can express in a name anyway; a detailed explanation of exactly what a service does should exist in documentation. Otherwise you end up with long names like "horizon-blob-profile-server" or "batch-process-execution-engine". Multiple words lead to ambiguity. Inevitably you end up using dashes, camel case, underscores, or no differentiation at all in order to represent word boundaries in different systems, because VCS, filesytems, domain names, and cloud systems all have different sets of permitted characters. This makes automating your infrastructure painful. And of course people resort to acronyms when discussing the services, which means everyone is forever getting the dfkg service confused with dkfg. "Whoops, I deleted the wrong database!"
  • allknowingfrog 4y ago
    I have this exact regret. Code may be meaningless, but acronyms are both meaningless and confusable.
• lamontcg 4y ago
  This is a good example of negativity bias. So you have to remember all these random names matched up with their functions, memorizing all of it, because that is far better than one of them being misnamed and having to remember that the broadcast-service does something else.
• ppqqrr 4y ago
  False dichotomy; descriptive names can and should be cute, if you're willing to spice them with a bit of analogy and/or irony. Problem is that most corporate programmers lack personality (and punk spirit, tbh), and use names as a way to make their code appear "compliant," (boring) deflecting attention and scrutiny from their work.
• imwillofficial 4y ago
  Names should be descriptive. Cute names are an abysmal time sink. Oh what does the quark service do? Who knows? Are there are 3 services named zoidburg? Oh well. Service name’s are best when it roughly shares what it does.
• spullara 4y ago
  When I worked at Twitter many services have bird names and some have descriptive names. The descriptive names are far better. Who wants to remember the user service is Gizmoduck? Also, I don't know where this guy works that a service changes what it does over time.
• sirsinsalot 4y ago
  I refuse to ever use homebrew because all the themed naming makes me rage. It is nonsense.
• kdamica 4y ago
  IIRC at one point at Uber there were three completely separate services named Polaris.
• bsima 4y ago
  > Your friend Sam is still Sam, even if Sam gets new responsibilities and sheds old ones. Does Sam's last name happen to be Smith or Cooper or any of the other thousand of occupational surnames people use? Just curious..
• imwillofficial 4y ago
  I worked on a service called the Bill Auditor Service. When people wanted to find out who, wait for it, audited the bills, they knew where to go. And sure we had some services where their name no longer reflected their purpose. Those were refactored and renamed when the time was right.
• shove 4y ago
  thats-bait.gif
• ChrisArchitect 4y ago
  Naming is one of the hardest things in computer science of course.... ..but also one of the most fun!
• janef0421 4y ago
  I think this is probably two far to one side. It is true that naming something purely descriptively may lead to misconceptions as its function evolves, but a "cute" name doesn't do anything to inform someone what it is. I would argue that best name has some semantic connection to the function, but is also somewhat abstracted; This allows it to be informative while accommodating evolution.
• ram_rar 4y ago
  Hard disagree. Especially for backend/infra or any cross team usage. One of my previous company widely popular for crunching logs had starwars esque names for various services and Kubernetes infra. It was a terrible decision, since it lead to another layer of abstraction to know what those meant in the context, also when employees churn, reorgs happen, a lot of this info gets lost into oblivion.
• pwinnski 4y ago
  If the reason for this is that it's hard to change names, then the solution is to make it easier to change names, not to use stupid names. A given service should run on hardware/VMs that are named related to that service, and if the service goes offline, so does that hardware or those VMs, to be repurposed (and renamed) into something else. Anything else leads to madness, or starts from madness.
• tastysandwich 4y ago
  Imagine starting at a new company and you view a big diagram of all the services. "Flipper connects to klunker, which has a database called plomb. There's an arrow going from gonky all the way down to zippydoo, which generates a report that gets handled by fogle. And all this is orchestrated by butt". I also like descriptive names because they help me fend off service bloat. "Sorry, it doesn't make sense to add bespoke client integration to report-generator. But we can make a new service which takes those reports and sends them to ABC Corp if you want."
• wlonkly 4y ago
  I worked at a place that did the typical geek naming thing, with the Greek and Roman pantheon. They were cleverly chosen, so that you could remember that "mercury" was the messenger, and so on. But still, you couldn't tell anything from a name unless you already knew the connection. So we went with serious names: Message Sending Service, User Account Service, and so on. And the result is that every service has a valueless "Service" appended to it and everyone just throws acronyms around now. So you can't tell anything from a name unless you already know the acronym. Overall I think the answer is that things that involve a lot of interaction can have creative names, and things that are rarely interacted with have to have more meaningful names. Call the monolith "Princess Unicorn". Everyone will end up knowing what Princess Unicorn is through proximity. But call the annual billing reconciliation process "Annual Billing Reconciliation".
• fsckboy 4y ago
  this is one of the designed benefits of hungarian notation, generating short, unique (not already overloaded) names that give a notion of type or class, and a distinguishing descriptor/mnemonic. these terms can take on a memorable cuteness factor without being a sledgehammer of cuteness that crushes any notion of meaning.