11 ms·

Software component names should be whimsical and cryptic

• barrysteve 4y ago
  Cryptic names will only have one outcome. The 'ingroup' whom understand the network of names will run the show and anyone who asks what AlphaBetaCharlie actually does, is at an eternal disadvantage. Judging descriptive names by their worst examples is not exactly a charitable interpretation.
• adhesive_wombat 4y ago
  I do like the Intel code names like Tiger Lake, Light Peak and Ivy Ridge. They evoke some kind of combination of Manhattan project megaproject and just-charted territory.
  • papito 4y ago
    Those are release names, like Sierra and Mojave for MacOS. Different. There, you can sort of go nuts. The product name is still, well, "processor".
    • adhesive_wombat 4y ago
      Even their product range names are "cool" (or at least carefully chosen by marketing to sound technological), like "Xeon" and "Itanium". Probably hard to get street cred for a cutting-edge processing monster named FluffyKitten.
    • 0x457 4y ago
      Product family is Core iX, Xeon, Atom, Pentium X etc. Intel® Core™ i9-9900K Processor is a product name. Lucky you generally only care about release names within a single product because thinking which one is Jasper Lake and which one is Alder Lake is not something I want to do. Even those product names are not excellent either: Intel introduced i9 which is essentially what i7 used to be and used to justify higher price - look i7 is the same price, but it's the brand new i9, that is totally wouldn't be called i7 5 years ago, that cost more.
  • MagnumOpus 4y ago
    I don't like them - they were OK when talking about 6-8 chips in 3-4 generations. But after the 30th different lake you get thoroughly confused. Apple did it better, switching from big cats to big cliffs after ten releases...
    • Hnrobert42 4y ago
      IMO, they would be even better if they would be even better if they were in alphabetical order. Would make it easier to remember which came first.
    • PurpleRamen 4y ago
      The names are all random and without obvious connection to the product, so does it real matter? The confusion comes from the amount, not the naming. So in this case, calling it an overused naming-scheme might be the better description.
    • speed_spread 4y ago
      Going from cool felines to places you fall from or wreck your ship into is an interesting analogy for OS X evolution.
• exmadscientist 4y ago
  Also, unique. Or at least unique-ish. Whoever named the ML thing "transformer" deserves a special place in hell. So many intriguing headlines, so few things worth reading. (I'm an EE, so I'm very interested in the other transformers. For some reason, the headlines for these things scan like they could apply to either. Alas, they don't.)
  • xiphias2 4y ago
    The EE transformer is just as descriptive than the ML transformer. Your complaint is similar to cryptography conference attendants hating the word ,,crypto'' to change from cryptography to cryptocurrency, but that's just the natural evolution of language with technology (not mentioning that the original meaning of the Greek word is hidden/secret).
    • saalweachter 4y ago
      Does naming a public ledger 'hidden/secret' really make sense?
      • xiphias2 4y ago
        Of course no, the new naming of crypto comes from cryptocurrency, which comes from currency based on cryptography. It's not the first time something like this happened, the only difference is that in the past languages evolved similarly in hundreds of years, now a new word can pop up in a day (but most new words get global in just a few years).
    • marcosdumay 4y ago
      The EE transformer was one of a few devices when it was created. It was not part of a field that had already hundreds of concepts with that same name, including a concept that describes everything that looks like a ML transformer.
• wwilim 4y ago
  Another reason is that people will _care_ about Shelob. It builds a community. They wouldn't care about an InternalWebCrawler.
  • speed_spread 4y ago
    Either they'll care or it will catalyze their hate of it. Strong names lead to strong emotional responses.
• eternityforest 4y ago
  Aesthetically, at this point descriptive names almost look unprofessional, or at least quickly made. If you call your thing "ui-state-syncer" I'm going to suspect it's not really a big budget mainstream thing. If it's called Vue, I'm going to think it's big enough that someone thought it was worth it to spend an hour thinking of names. It was intended to get big. This isn't some minimal internal thing for one specific use case that probably isn't mine. I'll be more likely to check it out. They also limit the scope of a project. If you have a "datasender" people will say "This shouldn't preprocess data! This shouldn't compress! This shouldn't intelligently decide when to drop frames! It should just send!" Now you gotta have a separate frame droppy preprocess thing, and the part that does communication has to tell it what kind of loss you have, but even that is not just sending data, so more likely you won't get that feature at all, or you'll have to go beyond the name. If you hate features I guess it's a good way to make them hard to implement.
  • Tade0 4y ago
    Seems that names for projects follow the same rule as troll names in the japanese light novel Overlord. Short names, like "Gru" were reserved for the most powerful trolls because there were only so many combinations of three letters. Long names on the other hand were a sign of weakness and cowardice - bringing ridicule to those who introduced themselves like that.
    • bombcar 4y ago
      If you are going up against Gothmark, Destroyer of Worlds you might have a chance. But if everyone calls the big bad Dennis you’re pretty much doomed.
    • HPsquared 4y ago
      Sed and awk kind of sound like high-level troll names.
      • koolba 4y ago
        Both of which cower in fear when vi strolls by.
• Tade0 4y ago
  My favourite example of how this can go sideways is BlueJeans - video conferencing software. There's probably some cultural context I'm missing here, but I asked around in the office and got a different answer each time as to why it would be named like that. That was 9 years ago and I still don't know BTW.
  • praptak 4y ago
    I'd say it gets the worst of both worlds, or maybe even worst of three worlds. It is long, it is cryptic, and it actually leads you down the false path of trying to guess why jeans and why they're blue. I mean if you go with cryptic then at least call it something short and obviously cryptic. "Chrome" good, "VersatileGopher" bad. PS Yes I know that Chrome actually has an explanation, but it does not sound like it means something that you could guess if you thought hard enough. I'm also not criticizing Ubuntu release names because the context is obviously different.
    • deleted 4y ago
      [deleted]
  • samatman 4y ago
    By contrast, Jitsi, while totally meaningless, is easy to remember. A whimsical name with no connection whatsoever to the application or library is misleading, a nonce word is better.
• xupybd 4y ago
  This is terrible advice. Cryptic names are horrible. It's a layer of cognitive overhead that no one needs. Yes if it gets so big that it's out grown it's original purpose that's a problem. But if it's really big people know what it is because it's big. If it's not that big rename it!
  • bayindirh 4y ago
    I opt to compromise and use middle ground name, which both related and fun. A tool for sending mails via Mailgun? “Railgun” then, for example.
    • bckr 4y ago
      This is my stance. 2 words: Memorable Use. Banana Cache Hadouken Security Service Lightfoot Containers I mean, this is pretty much the AWS formula.
      • bayindirh 4y ago
        For bigger services, it makes sense. For smaller utilities single word names are better IMHO. I'll keep this formula in mind too, and use it when I develop something bigger.
    • tetha 4y ago
      This is the right middle ground imo as well. It adds a bit of simple difference between the 15 different exporters, without being too far off. We have things like the "Tenant Saw" - extracts a tenant from a multi tenant system, or a foosystem-butler called Vlad - automating and scripting a bunch of busywork around the foosystem.
  • MrSqueezles 4y ago
    Yes. The advice is contextual. If you're making a public web framework, probably don't call it Web Framework. If you work at a company and you're writing the one and only hotel booking service, do call it Hotels instead of forcing your coworkers to memorize yet another cute name.
• qaq 4y ago
  If you went down the hell hole of microservices please do give descriptive names to services.
  • makeitdouble 4y ago
    I think the point still somewhat stands. Imagine a “UserProfile” service. It’s accessed from everywhere to show the handle name, address, icon etc. of your user. Your application grows and your users want way more customization, now they get personas and avatars and can show different profile to different people. Those are full of breaking changes that you want to isolate from the legacy “UserProfile”, how do you name your new service ?
    • qaq 4y ago
      https://UserProfile/v2/ https://UserProfile/v2/
    • Bootvis 4y ago
      UserProfile2
      • praptak 4y ago
        NewUserProfile, obviously :-)
        • em-bee 4y ago
          YeOldeUserProfile
      • saalweachter 4y ago
        Us3rPr0f1le
    • amirulmenjeni 4y ago
      > Those are full of breaking changes that you want to isolate from the legacy “UserProfile”, how do you name your new service ? Sound like it's better to make a new service. Isn't that the point of Single Responsibility concept?
• stavros 4y ago
  I like a middle ground, which is to name things with somewhat-but-not-entirely related names. For example, our authentication service is the Keymaster, the CI service is the Pipeline Worker, etc. That way, they're both whimsical but easy to remember, and if they drift a bit, it's fine.
• papito 4y ago
  There is this one man. He is great at marketing, and he once summed it up in just two sentences, but it's because he is so shockingly vain, vapid, and shallow that he is a genius at this art. "I try to step back and remember my first shallow reaction. The day I realized it can be smart to be shallow was, for me, a deep experience." I am not going to tell you who this is, but the point stands. The name should be easy to pronounce, it should zing, and your first reaction should be positive. Why do you have it? Doesn't matter. It's either there or it's not. A good name is at least half of a product's success.
  • tdeck 4y ago
    I suppose "Lemonade" the insurance company is a good example of this.
• joantune 4y ago
  Perhaps just give descriptive names and then change it when the scope changes?? "Problem" solved! Afraid of losing stars/dlds on the repo/etc? Make it clear in the Readme where the new project is. Have warnings et al for NPM projects. Ask npm/GitHub to allow name changes with redirects. This proposed "solution" is just bad for many reasons: You need to delve into the Readme to find out what it does. Imagine you're seeing a package.json and for each line you have to Google what's the project about SEO is best if name matches. These are enough *good* reasons why this advice is a bad idea
  • lupire 4y ago
    Renaming is work that doesn't improve the functionality.
    • smsm42 4y ago
      Only is you see "functionality" as "code being run in production". A lot of things then don't improve "functionality" - design documents, comments, use cases, tests, documentation, tutorials, etc. Proper software project still does all of it.
    • xpe 4y ago
      Functionality isn't all that matters. Software has many other aspects.
• h2odragon 4y ago
  Had a thing where the function that gave the user activation feedback was called "SparklePonies". Others found that confusing, especially people whose first language was not English.
• noufalibrahim 4y ago
  This reminds me of a "problem" we had in a code base that we maintained. It was a test framework written (and I use the term loosely) in perl. Someone wrote a throwaway script which later grew like a mould into a "tool" that was used by a large business group. None of the maintainers (including myself) knew perl properly. Of the 8k odd lines, 5k was a single function descriptively called `run`. All the variables were global since there were not functions to pass things into and we had a problem similar to what the OP posted about using variable names that someone else might be using somewhere else. One thing we needed was `machine_type`. There were some references to `MachineType` and `machine_type` and `machineType` so, a colleague decided to use the name `MaChInEtYpE` to make it unique. For all I know there are still people who trip over themselves on the keyboard typing this while maintaining it.
• javajosh 4y ago
  I hereby dub this "The Protectiva Paradigm" - an injunction to name things whimsically, not descriptively because a) its fun and b) the function of the thing changes so "give yourself wiggle room". The name itself comes from Dune, where the Bene Gesseret Missionaria Protectiva is itself whimsical (on some level) and cryptic. https://dune.fandom.com/wiki/Missionaria_Protectiva https://dune.fandom.com/wiki/Missionaria_Protectiva
• ChrisMarshallNY 4y ago
  I give mine “whimsical” names that have alphabetic first letters, and may correspond to positions in a hierarchy. For example, I tend to use a “layered” approach to servers. In one of my projects, the DB layer is the lowest, and is unnamed (it would start with “A,” if I had named it), so I named the DB connector “BADGER”[0]. The layer above that, is called "CHAMELEON/COBRA" (They are basically at the same logical layer). [0] https://littlegreenviper.com/miscellany/forensic-design-documentation/#badger https://littlegreenviper.com/miscellany/forensic-design-docu...
• xwdv 4y ago
  Stop with the cute cryptic names. If you want descriptive names that can be said with one word consider a good acronym, otherwise just say the whole name.
• 5350-uiop-1130 4y ago
  If i see the words "whimsical", "delightful" or {insert emoji} on a project readme, I will instantly dismiss that project. I've learnt not to trust such projects.
  • yencabulator 4y ago
    My trigger words are modern, elegant and expressive.
• kevincox 4y ago
  I larelt agree. I wrote a while back about how to make good names[1] Choosing whimsical names is a pretty good way to satisfy my two most important requirements. They are often unique and don't mislead people. Of course my ideal name would also give some hint about what it does (I think Google's BigTable may be one of the best named products) but I think this is far less important than the other two requirements. [1] https://kevincox.ca/2021/03/23/good-names/ https://kevincox.ca/2021/03/23/good-names/
• amadeuspagel 4y ago
  > CO_Cron: Despite the name, uses node-schedule rather than cron. That seems like a bad example. I've often googled "cronjob foo" for how to schedule something in foo. Seems like "cronjob" is a general term for scheduling now.
  • walthamstow 4y ago
    I think cron is short for chronos which is Greek for time. Chronological, chronograph, etc. So a cron job is simply a job that happens at a particular time.
• samatman 4y ago
  The throwaway comment about not using diagrams was truly baffling to me. A dashed arrow pointing in one direction is async data flow in that direction, A solid arrow is synchronous, and a swimlane / activity diagram shouldn't have two-way arrows in it (what would that mean?). How is that more likely to be read wrong than source code? Doesn't match my experience at all.
  • Ensorceled 4y ago
    > The throwaway comment about not using diagrams was truly baffling to me. Very bizarre ... also, why not BOTH a diagram and discription.
• jiggywiggy 4y ago
  Mysql_real_escape_string was a fun one years back for PHP. The original escape turned out to have character issues or so, so they made a new one: mysql_real_escape_string We were hoping they would find another issue and release a mysql_real_real_escape_string
• Davidbrcz 4y ago
  Please don't. My team work on a project with many "funny" names, including but not limited to, liboyster, libowl, several characters from Fort Boyard (https://en.m.wikipedia.org/wiki/Fort_Boyard_(game_show) https://en.m.wikipedia.org/wiki/Fort_Boyard_(game_show), patric the starfish.... It was awful to work with, please don't go that.
• amadeuspagel 4y ago
  Also an interesting question for company names. Google, Amazon, Apple are whimsical and cryptic. Microsoft hints at software, but is still not very descriptive. Facebook was descriptive, but they switched to Meta, probably to have a less constraining name.
• jkingsbery 4y ago
  I've gone back and forth on this. I think if you expect you'll only need a small group of people to know the name (the "Shelob" example at a startup), or you expect a large group but only are adding one name to learn ("Vue"), it's fine. The cute naming gets hard on larger projects. If you have to write a status or design document covering many teams, all with multiple cute names, that document will be impenetrable. It will be as hard as learning a new language - which in a sense it is, because your team will have created a new language that outsiders will need to understand in order to work with your team.
• PurpleRamen 4y ago
  If your functionality breaks the description, rename the software, or outsource the new functionality into a plugin or a new software. Pure Cryptic names are just cancer, even more than software which has grown out of its descriptive naming.
• ttiurani 4y ago
  > See, the scope and purpose of something changes faster than its name can. There's your problem. Create libraries that aim to do one thing and do it well. Once you release your project and have users that depend on your code, you owe it to them to maintain it in the original scope. If you have an urge to change your project's scope so much that the name should change, create a new library with a better name instead. p.s. Obviously does not apply to brand names, which need to be distinctive. p.p.s. Rich Hickey talks about this here: https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk
  • etothepii 4y ago
    Aim is the problem here. Many projects are built and maintained by people who have a use case. It may well fit that use case to add one extra feature to the library rather than creating a new library. I suspect that many of the examples provided (such as the Django project) evolved over time. It can also often be the case that once an implementation is done it becomes obvious that it actually does something very different to what you originally set out to do.
  • another-dave 4y ago
    Also comes back to the thing of "products end up modelling the organisational structure". If it's painless to create new internal products within your company & there is operational support for it, you're more likely to spin up a sister "EmailNotificationService" alongside "SmsNotificationService". If you have to jump through hoops to get sign-off and business cases etc and eitherways it's the same team responsible for both, people are more likely to say "let's just put the functionality in here"
  • Vinnl 4y ago
    > Create libraries that aim to do one thing and do it well. That's nice and all, but once you combine that with giving them descriptive names, you're going to have a list of hard-to-distinguish projects like: - css-min - css-polyfill - css-inline-min - css-inline-polyfill - css-script-min - css-script-polyfill - etc. Good luck clarifying what you're talking about. And of course, people will start using acronyms for all of them, and now you're back at cryptical names, with the added benefit of all the names sounding and looking similar. Or, of course, have inaccurate or inconsistent names. And then I didn't even get to the part where your categorisation turns out to not match the eventual scope, and they'll need to be split into css-server-min, css-client-min, etc.
• staccatomeasure 4y ago
  In general, disagree. And often the deep track names that are assigned in lieu of descriptive ones box out people that don’t share cultural touchpoints. https://twitter.com/staysaasy/status/1419274984459997186?s=20&t=Eg4YVzglF8CYL-iRgpD-vw https://twitter.com/staysaasy/status/1419274984459997186?s=2...
• shp0ngle 4y ago
  Actually agree. When I think of programming things I use the most, most of them have whimsical names that mean nothing. I mean, say, “grep” means… something with regular expressions I guess? But nobody cares. It’s just “grep”.
  • wizofaus 4y ago
    I can't believe I'd never thought to look up what grep stood for, or if I had it had failed totally to make an impression on me. But it doesn't even make any obvious sense - "global regular expression print"?? OTOH "git" doesn't stand for anything. "Cat" is rarely used to concatenate, "awk" you'd never guess unless you looked it up, "perl"'s status as an acronym is purely apocryphal etc. etc.
• blackbrokkoli 4y ago
  I like the distinction between tools and products here. If it's a product, by all means think about brand including a creative name. Might be vaguely related to the service, like YouTube, or completely wild, like Starbucks. If it's mostly a tool, being descriptive is just good SEO. You are not ever becoming a "household name" with a recognizable name when you are just supplementing a library supplementing a framework (or similar), and there is no reason to strive for that. "Django REST framework" shows up naturally when I google "django rest" and that just benefits both sides. If you are in between the two, opt for the middle: TweetDeck, MailChimp. That's my two cents anyways..
• deanjones 4y ago
  Also variables.
• motohagiography 4y ago
  I'm on the other side of this, as the author is advocating for using code words to compartmentalize infrastructure, which I think creates absurd bureaucratization and incentivises information hoarding, gatekeeping, and a bunch of other organizational antipatterns. Business owners and product managers tolerate the whimsy when systems work, but then suddenly when you can't make a feature commitment to a customer on whose relationship your business growth depends - because of the tech debt you accumulated by not priortizing UnicornPoo in your engineering roadmap, you realize your engineering team has essentially betrayed your organization so that they could be lazy and focus on science projects, and the code names were to obfuscate their commitments, and as an expression of spite and contempt for the people they took money from. Whimsy is cute initially, but it quickly becomes uncanny, and even repulsive to see adults acting careless. Cuteness is how children bargain with nature, and in a corporate environment that is about the livelihoods of adults, it is a liability.
• phdelightful 4y ago
  If you want to see this line of thinking taken a bit too far, check out the list of Trilinos packages on github: https://github.com/trilinos/Trilinos/tree/master/packages https://github.com/trilinos/Trilinos/tree/master/packages There's ~50, and nearly all of them are incomprehensible. It definitely makes things much less accessible to a newcomer / outsider. (Trilinos is a set of scientific / engineering libraries for HPC)
  • yencabulator 4y ago
    If you want to see this line of thinking taken to TempleOS levels, https://media.urbit.org/docs/hooncard-2022-04-03.pdf https://media.urbit.org/docs/hooncard-2022-04-03.pdf [PDF]
• dools 4y ago
  I don’t think you need to go full startup when naming stuff, but you also don’t have to go full bureaucrat either. I once created a PHP framework called RocketSled because it was “the fastest thing on rails” and that gave rise to somewhat whimsical but also descriptive names on the same theme: RocketPack: package manager DataBank: caching auto loader Murphy: automated testing Each of those modules is named quite specifically but that’s because they do one thing. I created an ORM tool called PluSQL, because it’s not an ActiveRecord style ORM but adds a bit on top of straight SQL statements. General enough that if I want to enhance the functionality beyond ORM I can, but also pretty easy to remember what it does from the name. The one library I created that may suffer from the problem described is Trellinator, which I recently began updating to work with the WeKan API, so maybe that should have been Kabanator … there’s still time. But I don’t think calling them all after my favourite Futurama characters would have been a better choice.
  • jgauth 4y ago
    Where does Murphy come from?
    • mavxg 4y ago
      Murphy's Law: Anything that can go wrong will go wrong.
    • layer8 4y ago
      Murphy’s Law.
    • adamauckland 4y ago
      I'm guessing something to do with Murphy's law
    • dools 4y ago
      Everyone else beat me to the explanation. The "Murphy" in Murphy's law also worked specifically on RocketSleds which is where the term "Murphy's Law" came from: "Following the end of hostilities, in 1947 Murphy attended the United States Air Force Institute of Technology, becoming R&D Officer at the Wright Air Development Center of Wright-Patterson Air Force Base. It was while here that he became involved in the high-speed rocket sled experiments (USAF project MX981, 1949) which led to the coining of Murphy's law." I was very pleasantly surprised by this coincindence when I was looking for a name for my testing package to go with my RocketSled framework. I named the framework RocketSled before I wrote the testing package, with no idea about the history of the term Murphy's Law. Interesting side note: murphytest lives on to this day as an NPM package, I still use the same approach to testing stuff now (ie. not worrying about any of the tenets of "Unit Testing", a practise which I called "Convergence Testing" at the time, but which probably already has a name, like Integration Testing maybe). [0] https://en.wikipedia.org/wiki/Edward_A._Murphy_Jr https://en.wikipedia.org/wiki/Edward_A._Murphy_Jr.
• ubertaco 4y ago
  I'm iffy on this for software (because you can always spin up a separate descriptively-named library to house the "scope creep"), but I'm 100% about this for team names at software companies, for the exact same reason: because you _can't_ easily "spin up" another team to handle the inevitable scope creep. Let's face it, no software company where any of us work has ever been satisfied with "well, we have enough features already, no need to build more." The incentives _always_ push for-profit software towards "build a shiny new feature", because you can't upsell existing customers the same features they already pay for, but you _can_ upsell them _new_ features. So companies monotonically grow their featureset. Companies also do _not_ monotonically grow their employee base, and _certainly_ not at the same rate as they grow their featureset. So, for example, the "email send team" of today will probably become "the email sending and rendering and link-tracking and some-of-the-reporting-but-not-all-of-it and some-of-the-public-API-but-not-all-of-it" team before long. And they'll probably also gain additional features along the way, some of which are likely to be even _less_ related to things like SMTP and MTAs (which they'll still regularly have to deal with). In the meantime, those "some-but-not-all" categories will be shared with other teams, usually in a way that's not neatly describable in 1-2 words. So do you keep constantly changing your "descriptive" team names and fleshing them out into entire often-mutating paragraphs so that they're _actually_ descriptive? Because you're _certainly_ not going to wait to build a feature until there's a new team for it. And what happens when you decide that some of those features should change hands to a different team? Time to go update all your CODEOWNERS files and ACLs and directories and everything so you can change the team's name again? Or do you accept that memorable-and-unique-but-not-descriptive team names like "Apollo" or "Wombat" are a better use of your time, and find other ways (like relating per-feature PagerDuty "services" to team-level escalation policies) to map "feature X is currently owned by team Y"? Because honestly? 70% of the time that you would want a "descriptive name" for a team, it's because you're trying to reach/page the right team to fix a problem. Set up feature/service definitions in your tools of choice (PagerDuty, Jira), and make sure those are many-to-one with the team definitions, and then ensure that those definitions can be easily modified/reparented later. To put it in programmer-friendly terms, don't use magic strings, factor out real identifier constants, and reference that constant instead of duplicating it. P.S. to those of you who might say "you can just pick a generally-descriptive-enough name without it listing every feature", I once worked on a team named "<Product> Email Team," and we _frequently_ got questions/tickets/bug-reports about email-related or email-adjacent features that were actually owned by other teams (either on a different product, or as more of a "downstream" thing). We also sometimes _didn't_ get questions passed our way that were related to the non-email features we'd accumulated over time (see also: featureset growth speed vs. "headcount" growth speed). We were eventually renamed "<Product> Email And Content Services Team", ironically because our existing "descriptive" name was deemed "insufficiently descriptive". Rather than fixing the problem, the new name in fact only exacerbates the problem, since no two people can clearly agree on what "Content Services" are.
• jeroenvlek 4y ago
  Everything in software (and life) is a trade-off and should be balanced and rebalanced. Something we just continuously fail to absorb in our true/false programmer brains, since everyone is always looking for those golden laws that always apply. "Always give cute names", "Always give descriptive names", "FP is always good, OOP is always bad", "Always test first", "Always test later" etc. Golden laws don't exist: Pick the best solution for your current situation and accept that your current situation will change. (Which is, again, a trade-off between now and the future!)
• Ensorceled 4y ago
  Inside this essay giving horrible advice, is more horrible advice: > Even worse are those ubiquitous diagrams everybody uses to communicate about software, where there’s a box labeled OrdersService with an arrow connecting it to a box labeled OrderStatusService. I don’t understand why anybody draws those. People like this are why there are documents with a thousand bullet points and no diagrams to help anyone actually visualize how this all fits together. It's like a children's song ... The foot bone connected to the leg bone, The leg bone connected to the knee bone, The knee bone connected to the thigh bone, The thigh bone connected to the back bone, The back bone connected to the neck bone, The neck bone connected to the head bone And by the end of it you still don't know what you are dealing with.
  • xani_ 4y ago
    Sure but what to do if all the good names for doing the thing the thing is doing are taken ?
    • alistairSH 4y ago
      If within the same system, you have multiples of "personService", "paymentService", and none them have unique features that can be used in the name, then you probably have a design problem.
    • the_sleaze9 4y ago
      When faced with the same problem, Elon went with X Æ A-12. Personally I prefer UUIDs for global uniqueness.
      • ThunderSizzle 4y ago
        c88990d0_c47e_4d8a_aa96_680d8b58192d_Service aka OrderService ca7f6516_337c_11ed_a261_0242ac120002_Service aka PaymentService I don't see that working out in the long run...
    • amccloud 4y ago
      Qualify the duplicate name with why you have a duplicate. Already have Service and need Service? How bout NewService and Service instead. Or ${NEW_TRAIT}Service and Service. (can replace Service with any domain) You could also just not duplicate and keep a single Service. Like other mentioned this is likely a design problem at any point names clash.
• emehrkay 4y ago
  I love writing libs and giving them unconventional names. See Khadijah a go struct to Cypher cRUD query generator https://github.com/emehrkay/khadijah https://github.com/emehrkay/khadijah
• bena 4y ago
  Next he's going to tell us the proper way to do cache invalidation.
• RcouF1uZ4gsC 4y ago
  I think software component names should all just be UUIDs. This way no one is misled by the name. Also, there is much less chance that an offensive name gets picked (either intentional or unintentionally). There is also much less risk of collisions. In addition, you don’t waste any time trying to come up with a name.
  • sebastos 4y ago
    And no pesky scope implied by the name! Now, each of the components can grow in a truly unconstrained manner, enveloping whatever random features were slightly more convenient to add there instead of in a new component. Amazing!
• yuan43 4y ago
  The author seems to be talking about names for two totally different things, lumping them under the term "component." Whimsical project name? No problem. Whimsical type name within a project? Really bad idea. Whimsical variable name? Don't even think about it. The concept the author is missing is "convention." Whimsical project names fall within a well-understood and used convention. The convention for type and variable names, however, is set by the standard library and these are almost always descriptive. Their purpose is, in the best case, to reinforce a ubiquitous language drawn from the domain.
  • ThePadawan 4y ago
    > Whimsical project names fall within a well-understood and used convention. Boy, I wish! I 100% second TFA when I tell you: There are a lot of really really boring people out there that just don't get it. They think "Product Data Exporter" is the perfect project name.
    • strken 4y ago
      If you call your data exporter "Asparagus" I will throw a thesaurus at you every day until you come up with a better name for it that has some kind of mnemonic link to what it does. "Data Exporter" is okay, but "Catapult" or "Superhighway" or another whimsical name would be okay too, so long as it loosely matches the problem domain in a memorable way.
      • reshlo 4y ago
        “Yeet”
        • ThePadawan 4y ago
          I personally would prefer my exporter to focus on precision, not distance. So clearly, it wouldn't be "Asparagus", it would be "Beef" (as in Kobe).
    • dzhiurgis 4y ago
• davelondon 4y ago
  https://www.dropbox.com/s/amoz52ja8got5wq/navigation.png?dl=0 https://www.dropbox.com/s/amoz52ja8got5wq/navigation.png?dl=... :D
• fiddlerwoaroof 4y ago
  I strongly agree with this. I’ve worked places that follow both naming styles and I’ve found it’s much easier to get up to speed if the services and repositories have names that don’t overload the language you use to talk about what you’re doing. E.g. if your service that sends out webhooks is called “webhooks”, then newcomers will always be confused about whether you’re talking about the concept or the implementation; if the service is called “voltron”, newcomers might not know what it does initially, but they can discover that pretty quickly.
• walnutclosefarm 4y ago
  There is a real world example of a complex, critical, domain that has followed this approach religiously for years: prescription drugs. Every prescription drug is given an essentially nonsense non-proprietary (generic) name, with only broad categories identified by a stem (drugs ending in "mab," e.g., are monoclonal antibodies, those ending in "vir," are anti-virals). Names that are suggestive of medical target or use, beyond what is implied in the stem, are not allowed. The system is international, with international bodies ultimately approving naming of drugs. The result - well, it works in some respects, but it would take a real optimist to say that brings any clarity or long term order to the process by which medical professionals learn or refer to the drugs they prescribe and administer, or that it plays much role in getting the right prescription into the right medicine cabinet and ultimately, patient. The names are confusing as hell, often unpronouncable (despite the orthographic and oral qualities of the names being considerations in name assignment) to anyone who doesn't know them well, professionally. And the common drugs - well, let's just say, you're far more likely to tell someone you're on Lipitor (a brand name, for marketing) than "atorvastatin".
  • kemiller2002 4y ago
    I've been on medication for years, and I still can't pronounce let alone remember it's name. God help me if it becomes critical I tell someone what it is, because I'm screwed if so.
  • Tomis02 4y ago
    That's actually a great example and it illustrates OP's point. If prescription drugs were given names based on their perceived meaning or target, things could get extremely confusing and/or misleading later when the meaning or target change (but the name stays the same). As it stands, choosing "random" names definitely seems like the lesser of two evils. The names may seem awkward at first but once you get used to them there's nothing particularly bad about them. > it would take a real optimist to say that brings any clarity or long term order to the process by which medical professionals learn or refer to the drugs they prescribe and administer In this case I don't think you can have the cake and eat it too, unless you can somehow prove that the chosen descriptive name will forever remain meaningful and descriptive.
• darylteo 4y ago
  Like this? https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ :D
• pnut 4y ago
  I'd be curious to hear thoughts from anyone with practical experience of urbit, considering their intentionally nonsensical naming choices.
  • habitmelon 4y ago
    The choice of using totally novel and cryptic names for everything was intentional. The project is ambitious, and aims to do a completely fresh stack, (OS, drivers, network stack, identity, filesystem, etc.). Given that level of ambition, the choice of names was done remind the user that this is not just Unix and TCP/IP re-written, this is a whole new alien OS, based on distinct ideas. The fact that Arvo (the kernel) doesn't even have a distinction between RAM and disk, or between PCI input and network input, is a much bigger deal than remembering that "Arvo is the kernel". OP is right that naming can give a false sense of familiarity, so inverting that for things like this makes sense. Create a false sense of un-familiarity, to keep the users paying attention while they learn what they are using. That's been my experience so far, a heightened sense of awareness while reading through the cryptic documentation.
• k__ 4y ago
  The biggest issue, I see with learning how software works, is common names. For example, game engine. Some library or framework, that helps you to build games. Nice. But what they do for you in detail isn't known, and can take months to understand. Unity does much more than Phaser. Angular is a total different beast than React. And this goes down to class names. MVC was the hype back in the days, but nobody knows what it actually meant in detail. Some people sat down and wrote some definition of the term, but no implementer adhered 100% to them.
• dhosek 4y ago
  I came up with the idea with my first PC to name my computers after Popes (skipping the numbers). That computer was named Peter. To be honest, I could not tell you the name of the laptop I’m typing this on right now without looking it up. So much for a clever naming scheme being useful.
• onion2k 4y ago
  “Descriptive” names don’t create transparency, they create the illusion of transparency. ...some of the time. The rest of the time they're actually very useful. Giving up any attempt at having a descriptive name just in case you get it wrong is throwing the baby out with the bath water. What's probably happened with a lot of poorly named projects is that when the scope changed to make the name redundant there was no attempt to change it. People get attached to their project names. It's possible that changing the name would require some effort, and maybe some cost (losing Github stars maybe?). That makes people stick with bad names. None of these things apply in a company. Just change the project name to reflect what it does now.
  • taeric 4y ago
    While I agree the extreme is clearly bad, I would also challenge if any project ever succeeded on any virtues of it's name. Such that I would see this as a very low stakes decision.
  • nine_k 4y ago
    Here I'm with the OP. A descriptive project name is hard, and gets lost among projects of a similar nature. Try to come up with descriptive names for projects like Git, Node.js, Docker, well, Linux. Well, BSD is formally a descriptive name, but it elucidates little. Of course there are some examples of somehow descriptive names which seem natural because of the sweeping success of the product: Photoshop, React. But they are few and far between. In short, project names are closer to branding than to engineering. Inside a codebase names should be descriptive, and appropriate effort should be allocated to name key things in an elucidating manner; nothing to debate here. But it's a very different context.
• plaguepilled 4y ago
  I agree with the author but for different reasons. Software should be fun! I love it when packages have goofy names. If I can shitpost with the language I'm going to get just a little more invested in it. And to be honest, even the 'serious' names fail at connoting respectability to begin with. Your grandpa would get annoyed just hearing the word 'containerisation' - and not just because he thinks computers are for nerds. The word sounds silly. People are saying this silly word at conferences and the word is still silly. So why not lean into the goof?
  • taeric 4y ago
    This feels like violent agreement with the point that the names should make you smile.
  • literallyWTF 4y ago
• philipov 4y ago
  Is this written by the same "Histocrat" as the channel on youtube that posts short history lectures?
• brianmcc 4y ago
  A handful of examples don't prove anything. If a Widget Lookup Service is used to lookup widgets for its entire lifespan, calling it Frodo isn't doing anyone any favours. And it's not like "oops some gadget polishing code fell into my widget lookup service": don't put inappropriate crap into your solution. Little discipline goes a long way.
  • tengbretson 4y ago
    Does knowing that it is called "Widget Lookup Service" actually convey enough information to you to be able to make meaningful changes to its implementation? If not, then its time to look up it up in your internal company wiki. Which name will yield search results specific to the service you are interested in, and which one will be heavily polluted by mentions of "Widget", presumably something common in your domain.
• sebastos 4y ago
  Author used to build authorization microservices, and now works at a company making a database product. Once again, somebody who works on some web service bs assumes that that's as hard as the world gets. If all of your software components are constantly changing their scope, it indicates you are doing a bad job of producing an up-front system design. If your experience causes you to scoff at the concept of producing a design up-front, or drawing diagrams of how your system works, then this indicates one of two things about your background. 1. You're a relatively junior engineer who has gotten used to thinking about productivity as slamming code that tweaks existing systems into new incremental features 2. You work on some fucking web service. Either way, your advice does not apply to the software engineering profession as a whole. Believe it or not, lots and lots of people write software, and not all of it is a web service or some tool / framework to help run your web service. There are many things out there are that can be envisioned, designed in detail, and implemented. And, crucially, in those cases, _it is wise to do so_. I know I'm being overly dramatic, but it consistently enrages me reading blog posts that, through ignorance or deliberate omission, speak as if the world of software is just writing web services.
  • hbrn 4y ago
    > you are doing a bad job of producing an up-front system design Or, it could be that you're actually innovating and requirements are changing faster than you write code. A late change in requirements is a competitive advantage. There definitely are systems where BDUF is a valid approach. But at the same time there are systems where making mistakes is the best way to learn. Emergent design is a thing.
    • sidlls 4y ago
      It’s not “innovative” to double-down on mistakes.
      • hbrn 4y ago
        Not necessarily, but could be. Have you heard of brainstorming? The worst thing you could do is to ban mistakes. Innovation is doing something that hasn't been done before. Inevitably that leads to mistakes. Being sloppy also leads to mistakes. Presence of mistakes doesn't tell you much. But lack of them tells a lot. If all your experiments are successful, it doesn't mean you're a genius. It means you're experimenting too slow.
• tester756 4y ago
  I recommend this book, it was written by top people with decades of experience in creating runtime, OSes, base class libraries, designing APIs, naming and so on Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (Addison-Wesley Microsoft Technology Series) 3rd Edition
• justinsaccount 4y ago
  I remember trying to fix Katello once and trying to figure out why "candlepin" was broken because it couldn't talk to "gutterball". Everything about the situation was terrible.
• ryandrake 4y ago
  OK, I guess I'll have to argue against. Please don't make component names whimsical. Your idea of whimsy and fun is potentially confusing or (worst case) offensive to others. Yes, make them unique and searchable. Yes, make them memorable and pronounceable. Yes, make them SFW. It would get tiring to have to keep explaining to new team members that our prime number generator is named "optimus" even if it was initially clever. I don't look forward to convincing my boss we need to pull in "libAnimeBabe" as a dependency even if it's the best parser for a file format we need to import. Nobody wants to find out a year after all of our marketing material is put together that our software name means "asshole" in another language. Don't make me have to pronounce an unpronounceable Gaelic word every time I do a presentation on our software stack because you're Irish and just had to name your component that way. There are lots of ways "whimsical" can backfire unintentionally. Save your creativity for the actual software solution.
  • eventhorizon77 4y ago
    Sorry but a prime number generator called "Optimus" is an awesome idea. I also kind of disagree that an "unpronounceable Gaelic word" is a poor choice. Seems like cultural discrimination. People all over the world write software, not just people who can pronounce English words.
• glacials 4y ago
  The author subjected themselves to confirmation bias by specifically searching for “despite the name”. Perhaps for every service that outgrew its descriptive name, there were 99 that helped people understand them more easily. If you were to compare the total time wasted by each category, I’m sure nondescriptive would come out as the most wasteful by far.
• charles_f 4y ago
  > “Don’t Be Cute > If names are too clever, they will be memorable only to people who share the author’s sense of humor, and only as long as these people remember the joke. Will they know what the function named HolyHandGrenade is supposed to do? Sure, it’s cute, but maybe in this case DeleteItems might be a better name. Choose clarity over entertainment value. Cuteness in code often appears in the form of colloquialisms or slang. For example, don’t use the name whack() to mean kill(). Don’t tell little culture-dependent jokes like eatMyShorts() to mean abort(). > Say what you mean. Mean what you say.” ~~ Clean code, Uncle Bob
• travisgriggs 4y ago
  I don’t care if you name them descriptively or weirdly, just please name them distinctly so when I have to do searches for them I come up with the right thing. The worst is Apple’s “Pages” and “Numbers”. Try doing a search for how to do something in either of these products. These are far from the only examples.
• robsws 4y ago
  I can just about tolerate this for brand names, as there's an additional set of requirements there, but for everything else, it's just gatekeeping and unnecessary obfuscation. If the purpose of something changes, fork it off into something new or just rename it if possible. Apache TinkerPop Gremlin might be fun for the creators, but not for anyone trying to understand what it does.
• AndriyKunitsyn 4y ago
  I couldn’t help but think about this video https://youtu.be/y8OnoxKotPQ https://youtu.be/y8OnoxKotPQ while I read this.
• vitiral 4y ago
  Here's my rules: if you're writing an API layer for your CustomerTransactions service then name it descriptively. If you're creating a tool to be wielded, name it creatively. If your software is a "final product" which by definition can grow in requirements then it's best to use a creative name. So if you build a programming language, a build tool, a dependency analyzer, or any kind of software that has the shape of a tool; which the user can wield in a variety of ways. I'm glad we didn't call a hammer a NailPounder since it can do so much more.
• msluyter 4y ago
  I have doubts about the author's overall point, but something to consider is how does a name help/hinder search? A name that's overly mundane, say, "Go", becomes problematic to google (hence the need to search for "golang" or add other terms). I feel almost like there's an analogy between choosing names for packages/projects and bird calls. Birds need to make their calls stand out in a given ecosystem. If you have a dozen projects like, say, "object-mapper," "object-db-mapper," "object-mapping", "object-mapper-thingy", "object-mapping-service", "db-object-mapper", it's hard to remember wtf was the one you need. If in such an ecosystem your project was named "Orangutan," it might stand out and be noticed. OTOH, if all projects in a given ecosystem have weird names like "murano", "swift", "glance", "hotdog", "gorilla", "zaqar", "cthulhu", "funky-chicken", "Sauron" or whatever, it may be hard to remember what they all do/mean -- yes, I'm giving you the side eye, openstack. In such a space, "cloud-disk" or something might win, IMHO. Slightly tangentially related is the use of odd words in log messages to aid searchability. I've been grateful for misspellings in the past, so I could easily grep for some critical log message containing `transation_id` or whatnot. (Good struct logging makes this less necessary, thankfully.)
• anonu 4y ago
  naming a project != naming a variable
• dudeinjapan 4y ago
  Radical idea: If the usage/purpose of something diverges significantly from its original name, change the name.
• codeflo 4y ago
  I don’t understand why it’s seen as a given that component names can’t be changed. All the given examples are public project names, where there’s a point to be made. For internal components though, where are your refactoring tools?
• dudeinjapan 4y ago
  In our stock trading algorithm, a parent order could have multiple child orders. If the parent order quantity was amended down, it might be necessary to cancel some of the child orders. The function name for this was called getSophiesChoice()
• electrondood 4y ago
  I work at a company where all of our services have stupid Greek code names. It adds a layer of obscurity, increases the cost of onboarding devs and context switching, etc. It's a goddamn stupid idea. The author here is equivocating opaque code names with multi-use repos. They're saying "see!? some repos on github do things in addition to their literal name." That has nothing to do with the fact that obscure code names are a stupid anti-pattern.
• TheDesolate0 4y ago
• rojobuffalo 4y ago
  I couldn't disagree more. In my opinion the golden rules of naming things are: 1. Names must be descriptive. 2. Names must be unambiguous. 3. Names should be no longer than they need to be to achieve #1 and #2. If your names are becoming less descriptive over time it's because you're not writing well. It's not easy to write well, but that's the job.
• skohan 4y ago
  I am on the exact opposite side on this. I always name things after exactly what they do, and I've never had an issue with one of my components taking on a role it wasn't intended for. If the scope changes, that component probably gets wrapped, or replaced, or somehow else room is made for a new properly named component or tool. This is something I am very grateful for when I return to a project after some time away and the code is documenting itself. But I'm also a fan of disposable code. If I'm actively working on something I probably rewrite more or less the whole project every 18 months bit by bit.
• tauwauwau 4y ago
  Krazam Microservices https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ I work on the same, but never learnt to use non-descriptive names.
• darepublic 4y ago
  One company in particular I worked for had exotic cute meme names for every big service in our service architecture. Sometimes conceptually related to what it did but often not. Damn annoying!
• ary 4y ago
  This is the absolute antithesis to how I operate and I disagree almost to the point of being offended. Try working in an environment where team leads are allowed to make up whatever names they want, create as many projects/services as they want, and organize everything based on whim. You get this: https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ For me that is not a parody, it's lived experience. > I’m probably being overdramatic there, but I hope my point is clear. “Descriptive” names don’t create transparency, they create the illusion of transparency. If you see that something has the name OrderStatusService, you will instinctively assume you know what it is and does, and you will probably be wrong. When what a thing does changes then the name should also change. I almost want to counter this Medium post by arguing that READMEs should be works of fiction because the project they describe might change over time.
  • dcow 4y ago
    Did you read the full essay? The author agrees with you regarding your ideals. The essay is a concession to reality. I’ve seen wildly out of date readmes that cause more confusion than help, for sure, too.
• latchkey 4y ago
  Can't have a post like this without a mention of this tweet: https://twitter.com/codinghorror/status/506010907021828096 https://twitter.com/codinghorror/status/506010907021828096
• khazhoux 4y ago
  > Names should make you smile. Yes, you, specifically. You should get a dopamine hit whenever something you created comes up, even when it’s in a sentence like “Shelob has broken again.” Fun is one of the most important things there is. I'll never understand this mentality, where a silly project name is a source of "fun." I would never dare tell anyone what should be fun for them... except in this case, where I will say that funny names are not actually fun. I can only imagine working in the author's ideal company: "Hey, does anyone know why Shmoop is down? I know I updated the BoomBoom and reconfigured Thanos, but now Klomgan is reporting a series of Lemonhead warnings. Should I talk to Meep team or the Chumbawumba admins?"
  • wsinks 4y ago
    I know this doesn't really advance the discussion that much, but... if you haven't seen this Krazam video, it's a sketch about that exact sentence there: https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ I'm completely with you that name choice is not necessarily where something needs to be fun, and most people don't realize that once you name something, it's probably around for 5-10 years whether you like it or not. Or if it succeeds or fails.
    • deleted 4y ago
      [deleted]
  • 0x457 4y ago
    > I'll never understand this mentality, where a silly project name is a source of "fun." I would never dare tell anyone else what should be fun for them... except in this case, where I will say that funny names are not actually fun. I worked in a company that would "break ground" a new microservice every other week with overlapping scope of other microservices. (poor planning in resource allocation), which lead to some services named after Greek mythology that loose describes what service does...sometimes... Then they started giving more descriptive names, services that just do X and named X, except later they started doing Y, and now it's confusing. Then we had service XYZ (abbreviated from what it supposed to do), it took too long to build, so naturally management decided to make a Z service and remove functionality from XYZ. I think the author comes from a similar place where scope for service is constantly changing, and silly names are the only source of dopamine.
• nocman 4y ago
  Naming things is hard. I agree that bad and/or misleading names are, well, bad. However, I don't agree that we should just give up and name everything {SomeCrypticNameIThinkIsCool}. Invest time in naming things well the first time. Invest time in renaming things to be more accurate when it is feasible.
• raygelogic 4y ago
  are we talking about project names or the names of classes and objects? if it's projects, ideally the long-term architecture is well enough understood to give the thing a whimsical yet meaningful name (ideally not cryptic). building a page caching service? call it gutenberg or something to start. when it inevitably grows past scope, it's ok. no one will care if gutenberg also handles analytics callbacks or whatever. classes really shouldn't change in scope, ideally, so it's probably better to be a bit more specific to their purpose. overall this is a good hot take, if a bit broadly put.
• gloryless 4y ago
  I work in web, and one guy did this for two modules in a non-critical server, just TWO before I flat out told him to stop. "What does X mean" was a common question across people who had actually seen the code before and forgotten, and it was absolutely the first question someone trying to learn the codebase asked. It was a frustrating and silly practice that added to cognitive load and corroded faith in the authors decision-making. In a team ecosystem where you probably need to optimize for readability and ease of use, try to be simple and accurate and get used to refactoring. Making up random shit is the worst advice I can think of.
• bob1029 4y ago
  Naming things is hard. I still get it wrong after a decade+ of building complex systems. Naming things is also very important. Having some common language or way to refer to the various abstractions in the business is essential for basic teamwork. Even if the name is a cringetastic take on a comic book character. As long as everyone agrees on the string literal, you will be able to make forward progress. If you aren't absolutely certain what something should be called (i.e. maybe you are prototyping a crazy new idea), just invent some crap to keep moving along. I've got a shitload of odds and ends in static classes simply named things like "Utility" and "Hack". When you aren't so invested in what something is called, I have found you are much more willing to get "creative" with it. Naming things can also start to imply some sort of structure, so keeping it flat like this helps reduce the cognitive load. On the other hand, maybe you should consider more precise, deliberate naming if the business at hand is relatively stable and complex. Banking is a great example of a domain where very precise type names can make a huge difference in productivity. There is a gigantic difference between a "beneficial" owner and a "beneficiary". Applying reductive/creative naming schemes to this domain would likely cause more harm than good. You can always rename stuff in the future. Even database schemas can be migrated over time without impacting live customers. You can even rename an entire company (i.e. Facebook => Meta).
• KronisLV 4y ago
  "Descriptive" names like in the article might not be a good fit, because they're just badly chosen and sometimes lie to you. I'd argue that actually descriptive names aren't the worst thing ever, I wouldn't mind seeing a project/source code repo named "Client Bill PDF Generator" as long as the name on the tin actually matches what's inside of it. Of course, that implies that in the case of scope creep you should be able to change it as necessary. What this avoids is the problem of not needing a glossary to figure out what "Shelob" is supposed to be in a list of 50 different services, though I guess if you wanted to go for something fun, might as well throw them together: "Shelob: Client Bill PDF Generator". It's kind of how I approach naming my homelab servers/saving SSH sessions, a randomly chosen hostname comes first, but what it actually does is appended to the connection name/monitoring dashboard name - mostly because what I use the servers for might change so often, that this is one of the use cases where "fun" names make sense. Actually, Dylan Beattie once described why "fun" names might make sense, in a conference talk called "Life, Liberty and the Pursuit of APIness : The Secret to Happy Code", though it also touched upon other aspects of development. Here's the video timestamp for the problem situation: https://youtu.be/BIkXid_pBiY?t=769 https://youtu.be/BIkXid_pBiY?t=769 Here's the video timestamp for the proposed solution: https://youtu.be/BIkXid_pBiY?t=946 https://youtu.be/BIkXid_pBiY?t=946 The argument went along the lines of "by giving it a name, you cut out a lot of the noise". Curious, I can kind of understand that point of view, even though I'm not inclined to fully agree with it.
• Nomentatus 4y ago
  What I take from this that across languages, we ought perhaps to have the option, now and then, to use names have two parts: blotwort.django_lint for example. The whimsical part is permanent, the descriptive part is ignored when compiled (has no semantic force) and can be changed as needed without altering how the program executes.
• cbushko 4y ago
  Think of the new people you hire! It is difficult enough being onboarded to a new company without having to learn two dozen names for random services and libraries. I feel sorry for each batch of Interns that start at companies that do this. Not only were the Interns learning how to build software but they also had to learn random names that they would not be able to use in their next placement. What is easier to understand at first glance? Picard stopped responding to Luke. Bilbo is also down! or PaymentService stopped responding to UserService. Database-XYZ is down! It might not be exciting but the cognitive load is much lower.
  • eipipuz 4y ago
    Except as the article says, names tend to stick, scopes don't. This PaymentService grew into fraud detection. So the new hire will be even more confused. Asking "What does Picard do?" is natural, where a new hire might have trouble asking "What does the PaymentService do?"
    • cbushko 4y ago
      As someone else mentioned in the replies, this sounds more of a problem of not having a top level design than a naming problem. You have bigger problems if your `PaymentService` morphs into the functionality of being a storage or user service.
      • jffhn 4y ago
        I would not say top level design. Software is often born out of software. It's more like a woman keeping her children in her womb instead of giving birth to them.
    • smsm42 4y ago
      I don't think somebody would be more confused to learn that payment service also deals with fraud (which is something a lot of people are aware of - every payment service on the face of the planet has now warnings about fraud) than having to deal with "Picard is not connecting to Bilbo because Legolas is refusing to pass KrumpleSnitch to Kthulhu". In fact, I'm not sure it's humanly possible to be more confused than dealing with something like that. And if you having a payment system that starts doing something payments systems traditionally don't do - like, I dunno, predict weather? - then you have a design problem and should refactor your system so your payment system doesn't do that anymore.
• rektide 4y ago
  Strong "Death of Perosnality"[1] vibes here! That was about ux, this is more about dx. In that thread I advocated pretty heavily for apps not being special[2], for their best service usually being to get out of the way, to be slim & light, focused less on initial charm & more on enduring usability. I think most of that applies here. The whimsy & fun is cute at first, but it's rarely long term magic. For new teams & outsiders, it's a pain. I've had to work eith a sync engine where there's 20 subsystems seemingly each named by randomly picking a name from Encyclopedia of Mythology. There's probably something cute & creative & whimsical to the authors, but as someone trying to use the thing, it's merciless & oppressive, a huge turn off. [1] https://tdarb.org/blog/death-of-personality.html https://tdarb.org/blog/death-of-personality.html https://news.ycombinator.com/item?id=32777411 https://news.ycombinator.com/item?id=32777411 (79pts, 3d agi, 63 comments) [1] https://news.ycombinator.com/item?id=32791861 https://news.ycombinator.com/item?id=32791861
• habitmelon 4y ago
  Urbit devs agree 101%
• btbuildem 4y ago
  Naming is hard. It requires an understanding of what a thing does (or more accurately, at the time of coming up with the name: what the thing WILL do). One useful practice I've acquired over the years is to make the names unique. It makes it easier to search for them later. Generally, I would lean towards descriptive names. If the name no longer fits the thing, that's a great warning about scope issues. If it sounds "weird" for other named things to be dependent on or be required by the named thing -- that's often a hint about a context issue.
  • mindcrime 4y ago
    Naming is hard. I mean, there's a reason the old joke goes: "There are only two hard problems in computer science; naming things, cache invalidation, and off-by-one errors."
• lee101 4y ago
  I called my startup https://text-generator.io https://text-generator.io despite the name ... it uses image recognition to help generate text and offers an embeddings API, trying to extend it now to generate other forms of content (images, audio etc) depending on the input which is unfortunate
• ArrayBoundCheck 4y ago
  What an awful article. I wish I can downvote
• z3t4 4y ago
  In functional programming most variable names are single letters, except for function names, they are either name of spices or animal parts.
• mkaic 4y ago
  As someone who's working on a project right now that's full of whimsical/cryptic names (project is called Sandman, modules within the project include Mystic, Hypnos, Lethe, Morpheus, Dreamer, and Lucid), this was validating to read. That said, if my project was anything more than a solo personal project, I'd only keep the Sandman top-level name and rename the modules to things like Parser, Server, Client, etc. to make them more maintainable by others. I keep them because I'm the only one working on the project and I quite enjoy the sense of Hollywood-hacker-montage they impart me when I'm debugging.
• cpeterso 4y ago
  This satirical video about microservices shows just how deep whimsical project names (and microservice architectures) can go. Displaying the user’s birthdate starts with BINGO (the service that knows everyone’s name-o) and ends with GALACTUS (the all-knowing user service provider aggregator) talking to EKS (Entropy Khaos Service), soon to be EOL’d by OMEGA STAR. https://youtu.be/y8OnoxKotPQ https://youtu.be/y8OnoxKotPQ
• fedeb95 4y ago
  This is bullshit. I don't want dopamine hits. I want money for my code. And guess what increases the money I get from my code? Naming stuff consistently with their meaning.
• labster 4y ago
  You could always take the approach of JRR Tolkien: come up with the name first, then try to figure out what the software will do from that name. In a hole in a database, there lived a hobbit.
• daveslash 4y ago
  I very often whip out this tried by true joke. People often think it's "just a joke", but I actually think of it more as an adage, as words of wisdom, that also just happen to be whimsical. There are only 2 difficult things in computer science: 1. Naming things 2. Cache Invalidation 3. Off by one errors
  • NaturalPhallacy 4y ago
    The number of times I've told it in an interview with a programmer and they don't laugh are horrifying. There's deep, memorable wisdom in there if you have any experience.
• HankB99 4y ago
  I'm old. I prefer a name that hints at the usefulness of a project. Now get off my lawn!
• switchbak 4y ago
  For an external/public project? Sure! For a release code name (like Debian does), yeah why not. For internal service names? No. Not unless there's an obvious connection to its role (ie: TrafficCop handles DOS attempts, etc) I'm working with some legacy code that followed this pattern for internal services. It's a nightmare. WTF is Bilbo, oh it handles 2fa? And what's Pippin again? And there's a dozen other examples, of course most of them are from LOTR. I literally have to maintain a mental mapping because there's no rhyme or reason to the choices. That's actively anti-developer, anti empathy and I hate it. It's not cute, fun, helpful, professional. I can't think of a single redeeming quality. Maybe it's ok for a prototype you intend to throw away because it's so ridiculous you don't want to use that name with your boss, so it encourages non attachment. If you really can't pin down a name that describes the thing you're making, maybe you don't know what you're making? Also, we can rename and/or retractor things. And we should if their responsibilities change! Edit: added distinction about internal vs external.
• honkycat 4y ago
  Even in the planning phase, when you have a new project, giving it a name helps in general conversation. It also gives it an exciting mystique and makes it seem like you still give a shit about the job.