[HN Gopher] Software component names should be whimsical and cry...
___________________________________________________________________
Software component names should be whimsical and cryptic
Author : honoredb
Score : 259 points
Date : 2022-09-12 10:09 UTC (1 days ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| exmadscientist wrote:
| 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 wrote:
| 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 wrote:
| Does naming a public ledger 'hidden/secret' really make
| sense?
| xiphias2 wrote:
| 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 wrote:
| 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.
| mkaic wrote:
| 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.
| rojobuffalo wrote:
| 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.
| ChrisMarshallNY wrote:
| 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-
| docu...
| wwilim wrote:
| Another reason is that people will _care_ about Shelob. It builds
| a community. They wouldn't care about an InternalWebCrawler.
| speed_spread wrote:
| Either they'll care or it will catalyze their hate of it.
| Strong names lead to strong emotional responses.
| gloryless wrote:
| 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.
| cpeterso wrote:
| 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
| xwdv wrote:
| 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.
| mouzogu wrote:
| 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 wrote:
| My trigger words are modern, elegant and expressive.
| amadeuspagel wrote:
| 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.
| cbushko wrote:
| 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.
| teeray wrote:
| If only the names were so plain. Usually they're longer with
| the intention of being plain, then they become opaque acronyms:
|
| PPS stopped responding to UDMS. CMS is also down! No, not the
| CMS, the CMS is fine... CMS-the-service is down!
| eipipuz wrote:
| 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 wrote:
| 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.
| plaguepilled wrote:
| 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 wrote:
| This feels like violent agreement with the point that the names
| should make you smile.
| literallyWTF wrote:
| msluyter wrote:
| 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.)
| jkingsbery wrote:
| 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.
| rektide wrote:
| 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://news.ycombinator.com/item?id=32777411 (79pts, 3d agi, 63
| comments)
|
| [1] https://news.ycombinator.com/item?id=32791861
| skohan wrote:
| 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.
| dudeinjapan wrote:
| Radical idea: If the usage/purpose of something diverges
| significantly from its original name, change the name.
| philipov wrote:
| Is this written by the same "Histocrat" as the channel on youtube
| that posts short history lectures?
| eternityforest wrote:
| 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 wrote:
| 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.
| OrangeMonkey wrote:
| I was literally - minutes ago - watching Overlord then saw
| this message just now. Small world sometimes. Rich world
| building that it can be referenced easily.
| Tade0 wrote:
| I hesitated to mention it because of the stigma associated
| with weebetry, but I'm glad I did.
|
| After all hackers were always - by and large - weebs, with
| their fascination with martial arts and Japanese culture.
| [deleted]
| bombcar wrote:
| 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 wrote:
| Sed and awk kind of sound like high-level troll names.
| JosephGuerra wrote:
| Bill, Bert, Tom, Sed and Awk. It kind of works.
| koolba wrote:
| Both of which cower in fear when vi strolls by.
| Karellen wrote:
| All fear the mighty `w`, `X`, and, most terrifying of all
| due to the uncertainty of their proper pronunciation,
| `[`!
| koolba wrote:
| But even he respects the one true troll :!
| davidkunz wrote:
| An indicator of the dangers of C.
| adhesive_wombat wrote:
| Back when a C functions and variables could only be 8 chars
| long[1], mid-to-high-level trolls lurk at every line.
|
| [1]: or rather, if they were longer, the first 8 had to be
| unique.
| munificent wrote:
| _> Aesthetically, at this point descriptive names almost look
| unprofessional, or at least quickly made._
|
| I think part of this is that in software ecosystems that have
| been around a long time, the most obvious descriptive name for
| a package tends to have been chosen by the package that got
| there first but is now has an API riddled with outdated anti-
| patterns and whose code hasn't been touched in a decade because
| eventually everything becomes a breaking change.
|
| The newer package has to pick a weird-but-available name, but
| has the luxury of rebooting with a cleaner, simpler API and an
| implementation free of "bugs" that must be kept around in the
| name of backwards compatibility.
|
| Once you experience enough of those, you subconsciously develop
| an association that "boring obvious name" equals "crappy API
| and weird behavior" while "weird random name" signals "nice
| modern API and coherent semantics". Of course, it's not always
| true, but humans are voracious pattern matchers and will create
| an association at the slightest hint of correlation.
| e1g wrote:
| As a counter example, there are plenty of successful
| projects/brands with highly descriptive names: TypeScript,
| RHEL, GitHub, AWS, GraphQL, HAproxy, Sendmail, QuickBooks, ...
| Joker_vD wrote:
| What is descriptive about "RHEL" or "AWS"?
| anonymoushn wrote:
| Red Hat Enterprise Linux and Amazon Web Services?
| ForHackernews wrote:
| "Amazon Web Services" could mean literally anything. It
| only seems obvious and descriptive because it's become a
| widely known brand.
|
| Compare: "Nile Online Frameworks"
| lupire wrote:
| > Compare: "Nile Online Frameworks"
|
| Those are synonyms. What is your point?
| PurpleRamen wrote:
| But, isn't AWS doing literally everything?
|
| No simple name can describe the job 100% after a certain
| level of complexity anyway.
| e1g wrote:
| I abbreviated on the phone, but the respective full names
| are "X Enterprise Linux" and "X Web Services" which are
| literal description of what their thing is. "RedHat" and
| "Amazon" are generic, but the product names are highly
| specific.
|
| I mean it could've been "RedHat Cthulu" and "Amazon
| RainBox".
| ForHackernews wrote:
| I strenuously dispute that "Web Services" is "highly
| specific".
| [deleted]
| marcosdumay wrote:
| It is about as specific as the product.
| dagw wrote:
| _QuickBooks_
|
| I'm assuming this is a tool for quickly laying out and
| publishing books. Or perhaps a tool for quickly searching for
| and downloading books to my iPad or ebook reader.
| e1g wrote:
| In that domain (accounting), the name refers to "doing the
| books" which probably predates the abacus.
| Ensorceled wrote:
| Yep, could also be those things.
|
| But accounts and bookkeepers all know what QuickBooks is
| and are quite happy to not have to explain to their clients
| why they need to spend $75 a month on "KowalaBabyPooPoos"
| or something equally ludicrous name.
|
| Which is the point which you probably didn't miss in the
| first place.
| amadeuspagel wrote:
| Apparently, there's an accounting software called Xero,
| they have the dotcom[1]. Pretty good name and domain IMO.
|
| [1]: https://xero.com
| fedeb95 wrote:
| 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.
| phdelightful wrote:
| 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
|
| 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 wrote:
| If you want to see this line of thinking taken to TempleOS
| levels, https://media.urbit.org/docs/hooncard-2022-04-03.pdf
| [PDF]
| Tade0 wrote:
| 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 wrote:
| 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]
| samatman wrote:
| 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.
| glacials wrote:
| 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 wrote:
| > "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
| codeflo wrote:
| 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?
| onion2k wrote:
| _"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 wrote:
| 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 wrote:
| 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.
| xupybd wrote:
| 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!
| MrSqueezles wrote:
| 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.
| wzdd wrote:
| I can easily imagine the conversation after everyone has
| started using Hotels to book meeting rooms as well, so I
| think this is an argument for the other side. :)
| rgblambda wrote:
| I don't even use Serverless Framework that often yet get
| irrationality annoyed at how generic a name it has.
| xpe wrote:
| If someone doesn't like something, they may criticize
| anything about the thing, such as (a) having or a silly name
| or (b) having a generic descriptive name. Sometimes you just
| can't win. Sometimes such 'spillover' criticism is better
| understood as collateral damage from deeper frustrations.
| pavlov wrote:
| This only works once though.
|
| In ten years, none of the original developers of Hotels are
| with the company. The new generation of engineers is upset
| both with Hotels' limitations and the fact that it's not
| written in XYZ language which they really want to have on
| their resumes.
|
| So they embark on a total rewrite of Hotels, and to emphasize
| the awesomeness, most likely it will be called either Phoenix
| (because one out of three internal 2.0 rewrite projects is
| called that) or Venice (because it's a place that has lots of
| hotels).
|
| As part of their ambitious rewrite, they also start building
| a custom message queue in XYZ. It's called Milan so there's
| now a cute city theme. A bunch of other exciting NIH XYZ
| greenfield projects spring up, all with city code names.
|
| Another ten years go by. A programmer complains to another:
|
| "Where I work is the worst. There's all these projects
| written in XYZ which nobody uses any more, and they're all
| named after random cities. Why couldn't they call the hotel
| booking service something descriptive."
| TakeBlaster16 wrote:
| I solve that by naming my greenfield projects "hotels_old"
| from the get-go. It makes things easier for the next guy
| who replaces it.
| npteljes wrote:
| They can also name it Hotels2. It's up to the people what
| they name it, some like cute names, some the descriptive.
| winReInstall wrote:
| Its something that works in the cloud on a server. Its a
| cloudcomponentprocessor. Thats exactly what it is, what it
| does and absolutly context free.
|
| Descriptive alone does not cut it.
|
| Bonsupoints if your software throws errors, that throw
| customers. "I want to book a flight to NY, but it keeps
| saying Venice:DB is full"
| jayd16 wrote:
| How about just Hotels 2.X.X.X? Honestly, not much reason it
| can't be the exact same namespace depending on the language
| and whether the new and old would be imported by the same
| project.
| [deleted]
| doubled112 wrote:
| I know! Hotels-rs
| _1 wrote:
| My company has been throwing `-ng` on all the new
| versions.
| pindab0ter wrote:
| What's 'ng' short for? Next generation?
| unethical_ban wrote:
| Until that's expired. project-ng-ng? (I know the pain, we
| did the same thing at work).
| mattkrause wrote:
| No, `project-ds9` is the obvious upgrade path.
| doubled112 wrote:
| They included the "the" in placed I've worked. project-
| tng
| JasonFruit wrote:
| project-picard
| zem wrote:
| enterprise software at its finest
| 0x457 wrote:
| `-ng+`, `-ng++`
| jstimpfle wrote:
| It says "component". How many components do you have? I suppose
| if need to deal with more than a dozen components
| simultaneously, something is wrong. What is worse, the overhead
| of maybe not knowing a one-word description of component
| FancyName once in a while (so you have to look it up, pressing
| F12 or such), or having to deal with a obsolete, too long name
| (trying to be clear, or having too disambiguate between
| multiple redesigns), or unfitting name: all the time you're
| working with the thing?
| xupybd wrote:
| Screens are huge now. You can fit long names. Auto complete
| makes typing long names easy. Let your code read like prose.
| Save the brain for solving the business problems not for
| understanding the code.
| userbinator wrote:
| Long names are easier to read the first time, and become an
| impediment thereafter. Especially when you have multiple
| long names that differ only in a few characters.
| hulitu wrote:
| Not really. Screens are wider. An older 21 inch was taller
| than a 24 inch tft
| thiht wrote:
| > Cryptic names are horrible. It's a layer of cognitive
| overhead that no one needs
|
| I disagree with that. Cryptic names can become jargon, and
| jargon is useful in expert teams. At my last job we had a
| service whose role was to convert operations from system A to
| system B so at first we named it
| systemAOperationsToSystemBOperations. The name was clear but it
| was a pain in the ass to talk about it. We renamed it adios as
| a shorter name (irks like a fake acronym of the initial name)
| and it became way easier to talk and reason about our system.
| We lose a few minutes once in a while to remind juniors what
| adios does but we gain an efficient name to discuss the service
| day to day.
| [deleted]
| Vinnl wrote:
| The point is that descriptive names tend to either be overly
| generic (also a cognitive overhead, especially when you have
| multiple such generic names), or too specific and therefore
| quickly inaccurate (and even larger cognitive overhead).
|
| Oh, and as for "If it's not that big rename it" - this article
| is specifically about things that are hard to rename (e.g.
| public facing APIs or libraries):
|
| > Now, if a name is going to be easily changeable forever,
| please do make it descriptive.
| bayindirh wrote:
| 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.
| tetha wrote:
| 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.
| bckr wrote:
| 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 wrote:
| 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.
| barrysteve wrote:
| 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.
| qaq wrote:
| If you went down the hell hole of microservices please do give
| descriptive names to services.
| makeitdouble wrote:
| 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 ?
| 0x457 wrote:
| Tell me you don't version your APIs without telling me you
| don't version your APIs.
| makeitdouble wrote:
| You version your APIs, but do you version your services ?
|
| Think of your new service as having a different deployment
| target, its own DB, and could be under a different repo
| altogether.
| Bootvis wrote:
| UserProfile2
| praptak wrote:
| NewUserProfile, obviously :-)
| em-bee wrote:
| YeOldeUserProfile
| saalweachter wrote:
| Us3rPr0f1le
| samatman wrote:
| I mean, I'd call it the FaceBook in the first place but I'm
| already on team whimsical.
|
| Some of you are thinking, well, what if you need to interface
| with facebook dot com? Easy, I'd call it the SneedFeed. If
| you know you know.
| amirulmenjeni wrote:
| > 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?
| makeitdouble wrote:
| You got me confused.
| qaq wrote:
| https://UserProfile/v2/
| Jarwain wrote:
| UserPersona, where a single UserProfile may have multiple
| UserPersonas?
| dools wrote:
| 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 wrote:
| Where does Murphy come from?
| mavxg wrote:
| Murphy's Law: Anything that can go wrong will go wrong.
| dools wrote:
| 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.
| adamauckland wrote:
| I'm guessing something to do with Murphy's law
| layer8 wrote:
| Murphy's Law.
| tester756 wrote:
| 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
| raygelogic wrote:
| 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.
| PurpleRamen wrote:
| 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.
| AndriyKunitsyn wrote:
| I couldn't help but think about this video
| https://youtu.be/y8OnoxKotPQ while I read this.
| dudeinjapan wrote:
| 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()
| tauwauwau wrote:
| Krazam Microservices https://www.youtube.com/watch?v=y8OnoxKotPQ
|
| I work on the same, but never learnt to use non-descriptive
| names.
| latchkey wrote:
| Can't have a post like this without a mention of this tweet:
|
| https://twitter.com/codinghorror/status/506010907021828096
| ttiurani wrote:
| > 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
| jayd16 wrote:
| Exactly. Don't just cram functionality into the closest thing
| at hand without any thought and you won't have to worry about
| scope creep ruining the name of that thing.
|
| If you want to make new and different things, just do that.
| hulitu wrote:
| like libcaca. Caca means sh*t in some languages.
| another-dave wrote:
| 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"
| JosephGuerra wrote:
| In theory, it makes sense that you would just create a new
| library with a better name, but if the original product has
| been on GitHub long enough to have amassed followers and a
| significant number of stars, they may be hesitant to have to
| ask those contributors to re-add the new repo.
| Vinnl wrote:
| > 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.
| lelandfe wrote:
| And then someone makes a package to combine all of them, and
| then someone makes a package that combines that combining
| package with another combining package, and then the author
| of `css-script-polyfill` deletes the repo, and we're dealing
| with another leftpad
|
| https://qz.com/646467/how-one-programmer-broke-the-
| internet-...
| TkTech wrote:
| I can't be the only one that just includes any dependency
| with a permissive license? `git subtree` is so ridiculously
| easy for the larger dependencies and 90% of these projects
| are sub-500 lines in a single file, just include them.
| dmitriid wrote:
| > you're going to have a list of hard-to-distinguish projects
| like:
|
| What's hard to distinguish? These are projects that do
| something with CSS. If you don't need css, you skip them. If
| you need a polyfill, you only look at polyfill ones to see
| what you need.
|
| Now, let's imagine your list is "creatively" named like
|
| - shelob
|
| - arcana
|
| - custard
|
| - escalope
|
| - virtuocsso
|
| - jester-css
|
| - etc.
|
| Ah yes, this is so much easier to distinguish, isn't it?
| Vinnl wrote:
| They're hard to distinguish in the sense that a colleague
| might ask something like "hey can you publish a new version
| of css-script-min" and you accidentally publish a new
| version of "css-min" or "css-inline-min" or whatever
| instead.
| dmitriid wrote:
| That's such a minuscule problem compared to trying to
| figure out which of the insane names is the one you need.
| etothepii wrote:
| 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.
| habitue wrote:
| > Create libraries that aim to do one thing and do it well.
|
| This is a thing people like to repeat over and over again, but
| just really isn't actionable. The world is very high
| dimensional, it's always a judgement call what to cluster
| together and call "one thing". Especially in software where
| everything is made up and is constantly changing.
|
| People often like to refer to things like unix tools etc as
| doing one thing and doing it well, but all those tools have
| grown a ton of command line args, and have backwards
| compatibility issues that prevent them from doing their job
| "well" in the modern era. So people write new tools or just
| hardcodes a ton of command line flags into aliases by default.
| Many default settings on unix tools are awful. Why does grep
| not use regex by default? Why doesn't echo support newline
| escapes by default? Which tools use color by default?
|
| Reality is a mess, and it's an illusion that you can do "one
| thing"
| stavros wrote:
| 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 wrote:
| 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 wrote:
| I suppose "Lemonade" the insurance company is a good example of
| this.
| fiddlerwoaroof wrote:
| 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.
| darepublic wrote:
| 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!
| Ensorceled wrote:
| 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.
| silent_cal wrote:
| This is a great diagnosis. I hate to assume things, but
| sometimes I almost get the impression that some software
| developers are pulling an "I am very smart" move by making
| things more cryptic than they need to be.
| NaturalPhallacy wrote:
| The ones who do that I've found to be less experienced. Once
| they've had to deal with _their own_ bullshit, they tend to
| grow out of it. Even you don 't know what that code you wrote
| a year ago is doing.
| xani_ wrote:
| Sure but what to do if all the good names for doing the thing
| the thing is doing are taken ?
| alistairSH wrote:
| 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 wrote:
| When faced with the same problem, Elon went with X AE A-12.
|
| Personally I prefer UUIDs for global uniqueness.
| ThunderSizzle wrote:
| 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 wrote:
| 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.
| joantune wrote:
| 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 wrote:
| Renaming is work that doesn't improve the functionality.
| xpe wrote:
| Functionality isn't all that matters. Software has many other
| aspects.
| lee101 wrote:
| I called my startup 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
| habitmelon wrote:
| Urbit devs agree 101%
| TheDesolate0 wrote:
| emehrkay wrote:
| I love writing libs and giving them unconventional names. See
| Khadijah a go struct to Cypher cRUD query generator
| https://github.com/emehrkay/khadijah
| justinsaccount wrote:
| 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.
| kevincox wrote:
| 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/
| anonu wrote:
| naming a project != naming a variable
| travisgriggs wrote:
| 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.
| btbuildem wrote:
| 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 wrote:
| _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."
| brianmcc wrote:
| 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 wrote:
| 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.
| dhosek wrote:
| 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.
| h2odragon wrote:
| 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.
| khazhoux wrote:
| > 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?"
| 0x457 wrote:
| > 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.
| dylan604 wrote:
| >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.
|
| Upon the recognition of this is the time you should have your
| resume updated and you start responding to some of those
| LinkedIn reps that have been emailing you.
| inanutshellus wrote:
| You chose childish names one'd presumably be embarrassed to say
| to an outsider, but... Assuming you can stomach saying the
| project's name out loud, what's to lose?
|
| What method would you propose teams used to name a project, in
| which "fun" names are discouraged?
| Lendal wrote:
| Klomgan? This argument is a straw man because those names are
| all ridiculous and defeat the purpose of the naming strategy.
| If a real organization adopted the naming strategy described by
| this article, reason would quickly become a part of it, and all
| those names would therefore be disqualified. Nobody knows what
| a Klomgan is and it's a made-up word that's difficult to
| pronounce. Why would anyone suggest it? How about marshmallow,
| lemonade, candlestick, or zephyr? Those are some simple
| dictionary names that are easy to say and aren't overly
| distracting or offensive.
|
| Maybe "whimsical" isn't an accurate moniker. Generic or Common
| is how I would label the naming strategy described by this
| article. "Whimsical" is just asking for trouble and opens you
| up to overtly stupid names like "Chumbawumba."
| pitaj wrote:
| I think Chumbawumba would be a good name. Just nickname it
| Chubby or Chewy. It's not significantly worse than
| Kubernetes.
| khazhoux wrote:
| Well, Shelob has no meaning to me. And yes, I know now where
| it comes from, but I haven't read the books.
|
| The article says "names should make you smile." And really,
| does anything make a person smile more than Chumbawumba? They
| get knocked down, _and they get up again!_
| yencabulator wrote:
| The article specifically uses "Shelob" as an example of a
| desirable name. The comment you are replying to is not a
| straw man.
| aantix wrote:
| "I've lost the bleeps, I've lost the sweeps, and I've lost the
| creeps.
|
| The what?
|
| The what?
|
| And the what?"
| wsinks wrote:
| 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
|
| 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]
| sebastos wrote:
| 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.
| WalterBright wrote:
| > speak as if the world of software is just writing web
| services.
|
| So true. Web services are just a distraction from real
| software, which is writing compilers.
| rcoveson wrote:
| I can be dismissive of webdevs myself but this comment is too
| bitter for my taste. It sounds like you learned the salary of
| your greenhorn webdev nephew recently.
|
| The author did hit on the truth, no matter how he arrived
| there. Descriptive names are prone to collision, misdirection,
| and are much too long unless you use acronyms (in which case
| you may as well come up with a whimsical, pronounceable, unique
| name and just backronym it). This isn't a new idea. Lots of
| greybeards know this and name stuff accordingly.
| sebastos wrote:
| It's _A_ truth, but it's a truth that is inextricably
| intertwined with a certain context. If your software
| components are services running in the backend of a large web
| service company, then their purpose is likely to mutate as
| time goes on. In that paradigm, I totally believe it tends to
| be true that you're better off giving up from the beginning
| and just choosing unique names from the get-go. Your system
| is more like an ecosystem of organisms that will grow and
| adapt.
|
| But in OTHER contexts, your software components might be more
| like organs. If the heart has also become responsible for
| digestion, then it indicates your system design needs to be
| revisited. In lots of software projects, this is not an
| untenable proposition, such as it presumably is in a web
| service company.
|
| As somebody who works in one of those other contexts, it's
| important to me that the web service monoculture be correctly
| contextualized. Otherwise you have people cargo culting it in
| situations where the wisdom no longer applies. That's
| probably why I'm being so bitter. :(
| rcoveson wrote:
| I'm saying it's not just webservice monoculture. It
| predates _the web_. Which is a better name, MS-DOS or
| Linux? BCPL or Perl? Source Code Control System (SCCS) or
| Git?
|
| If a name is going to last a long time, and face a lot of
| different people, and have lots of relationships and sub-
| names of its own (e.g. "github"), then it's far better that
| it be short, unique, and memorable than that it be
| descriptive. There's nothing web-development-specific about
| that. Big projects get Name-names, like companies or
| people. Always have.
| sebastos wrote:
| Maybe we're getting into semantics, but you're listing
| the names of full software products or outward-facing
| open-source projects. The world is rarely coordinating to
| refactor responsibilities between different software
| products, since now you're talking about trading
| functionality across company / organization lines. At
| that level, I'd definitely agree that software is clearly
| a bazaar, and a whimsical, cryptic name is at its best.
|
| "Software component" has the connotation, to me at least,
| of being an inward-facing _piece_ of one of these
| products. It is but one component of a system, and thus
| it is to be understood by its function within that
| system.
|
| I think in many domains, the best advice is to name those
| components helpfully, and to think about the component's
| role in the system. To start adding functionality to the
| component outside the scope of its name is to invalidate
| your design. There is no reason to bloat this component.
| You'd rather create a new component to handle the
| previously overlooked role in the system. This is made
| obvious when you take limiting cases, like designing a
| moon lander. Here, the software design must be purposeful
| and optimized, and it only needs to work once. In the
| opposite case, the component is a web microservice - a
| living thing managed by a 1-pizza team that always needs
| to be turned on. Uptime and speed of implementation are
| at a premium, and creative ways to add new functionality
| on existing systems are seen as a net good. Here, the
| article's advice might be good.
| rcoveson wrote:
| Moon landers all get names. Even moon landers that never
| made it past the design phase probably had codenames.
|
| You've stumbled on _yet another_ situation where you
| should give something a cute name instead of a
| descriptive name: If there will be many implementations
| of the same thing over time. Each generation of Intel
| processor, each sort algorithm (TimSort, thanks Tim),
| each rocket, each mid-sized sedan.
|
| Now, do the individual software components within a moon
| lander get names? That depends! Are they re-used between
| landers? Are there many different implementations of the
| same component to choose from for each mission? The more
| affirmative the answers to these questions, the more
| likely it is the component will have/should have an
| actual name, instead of just being, say, "allocator.c".
|
| There are just so many reasons you might want something
| to have an actual name. Competing implementations or
| historical implementations, userbase size, project
| longevity, researchability. And they're all subject to
| change in the future (and renaming sucks). I have a hard
| time faulting anybody for giving their little binary data
| format a name like "parquet", even if it's tiny and only
| used in one place by one other thing and might never have
| any users. Because it might end up used for a long time,
| or by many people, or in a period of competition with
| another implementation of the same thing. If any of those
| things comes true, you're going to be glad you didn't
| name it "Hierarchical Data Format".
| yencabulator wrote:
| Big projects, fine. "Software components"? Most of those
| aren't big projects.
| rcoveson wrote:
| The start of the post clarifies:
| "services/repos/libraries".
|
| And yeah, all of them start at zero lines of code and
| zero users. Naming things sucks, but renaming things
| sucks worse.
| hbrn wrote:
| > 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.
| marcosdumay wrote:
| I have nothing against undescriptive product names. But if
| you are constantly changing the entire problem your software
| is intended to solve, you have a problem.
|
| And if you just happen to change it eventually, it's best for
| everybody if you go and make it a different project with a
| different name. Descriptive or not.
| __t__ wrote:
| Commercial software is mostly to solve real world problems.
| Real world problems can change very quickly and as such,
| software changes too.
|
| Sure constantly changing in the complete opposite direction
| is probably a sign of something wrong, but changes are
| inevitable and we can't expect to reinvent the wheel or
| start a new project as you say when you can potentially
| reuse what you already have.
| marcosdumay wrote:
| > Real world problems can change very quickly and as
| such, software changes too.
|
| So you keep the old product, and make a new one for
| solving the new problem. (You can even sell them on the
| same package.)
|
| The alternative will have almost all of your customers
| badmouthing you because they brought your product, and
| you pulled the functionality out of their feet.
| jstimpfle wrote:
| You make a new one and what name will it get? :)
| marcosdumay wrote:
| Well, as I said earlier, I don't care much about what
| camp you side here.
|
| The one important thing is that if you decide you must
| solve some completely different problem, you should do it
| with a completely different product.
|
| So the argument that a nondescriptive name allows you the
| freedom to change the product is bad. You never have the
| freedom to change the product.
| sidlls wrote:
| It's not "innovative" to double-down on mistakes.
| hbrn wrote:
| 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.
| mindcrime wrote:
| _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._
|
| This strikes me as a false dichotomy. The choices aren't
| limited to "BDUF" OR "NDUF" (No Design Up Front). There's a
| continuum along which the amount of up-front design that is
| required can range. I prefer the term SDUF (Sufficient Design
| Up Front). And of course we all have to keep in mind that
| design and architecture aren't things that _only_ happen "up
| front". Design and architecture work-streams should continue
| throughout the lifecycle of the project, IMO. The relative
| weighting of the different work-streams can vary, but the key
| is that it doesn't just end after the first
| (iteration|sprint|phase|whatever-you-call-it).
| bcrosby95 wrote:
| SDUF and redesign as necessary is where my job mostly
| falls. If we're facing an unreasonable deadline, "redesign
| as necessary" can turn into "just hack it in" though, which
| is what I'm currently dealing with.
|
| FWIW most of our deadlines are reasonable.
| dang wrote:
| Please don't cross into personal attack.
|
| Also, please don't fulminate in HN comments.
|
| https://news.ycombinator.com/newsguidelines.html
| JimmieMcnulty wrote:
| Isn't describing this comment as "fulmination" snarky, which
| is itself a violation of the guidelines? It's at least a
| shallow dismissal of their opinion, for sure.
|
| How can you expect people to follow these rules when you
| yourself don't? Looking at your history, you[0] leave[1]
| comments[2] like[3] this[4] (shallow dismissals at best, and
| snark at worse) pretty[5] consistently[6]. What gives?
|
| [0] https://news.ycombinator.com/item?id=32808611
|
| [1] https://news.ycombinator.com/item?id=32807734
|
| [2] https://news.ycombinator.com/item?id=32803087
|
| [3] https://news.ycombinator.com/item?id=32799206
|
| [4] https://news.ycombinator.com/item?id=32798437
|
| [5] https://news.ycombinator.com/item?id=32772307
|
| [6] https://news.ycombinator.com/item?id=32773948
| Kiro wrote:
| Likewise your comment shows that you are also a relatively
| junior developer, without much real-world experience. So the
| truth probably lies somewhere in between.
| c0mptonFP wrote:
| I think you could've made your point without letting your
| insecurity shine through.
| kuramitropolis wrote:
| We don't need no security. Just here to remark that I quite
| like the tone of GP even though I kinda fail to see the point
| being made. Fuck what Web services have become and fuck the
| people who piled all this accidental complexity on top of
| what was essentially a very elegant kind of software, and
| could've remained one
| dcow wrote:
| What bothers me about this comment is that it's a roundabout
| ad-hominem rebuttal to the author's argument. Reading the
| essay, I have no reason to believe the author has only ever
| worked on web services. But I would if I was angry and trying
| to discredit the author.
|
| The author actually does discuss the nuance. They argue exactly
| your point saying that their "considered harmful" advice only
| applies in situations where the scope of the component is
| ambiguous/fluid/unknown/otherwise prone to change over
| time/etc. In cases where you have a mature fixed design, choose
| an appropriately descriptive name.
|
| I'm glad you have only ever worked on projects that were
| perfectly designed up front. Sounds like the dream. For the
| rest of us, we engineer in reality. And I find the author's
| point apropos.
| gabereiser wrote:
| I came here to write something similar. The article lists a few
| repos as examples of bad naming when the reality is, it's
| examples of miss-naming. For a long long time I've convinced
| people to use literal names for things and not get creative. A
| _BillingStatusService_ , as the author has cited, isn't an
| example of a bad name. It's an example of bad engineering that
| it does more than _BillingStatus_.
|
| Often times when people get creative with names, the meaning
| dies with them. When they leave the company so too does the
| reasoning behind the name.
|
| The author conflates service bloat with bad names. Fix the
| bloat and the name will make sense. If you have an app called
| "Authorizer" and it does email, you failed. If you have a
| service called "InfraValidator" all it should be doing is
| validation. If it's not (such as tensor flow's infra validator)
| then the service/app/codebase is misleading and needs to be
| renamed after what it does.
|
| I also hate to see overly descriptive names.
| Package/crate/bundle/module should help classify the name of
| the class/object/func_collection.
|
| Names like "EnvironmentPostProcessor" (Spring Boot) is succinct
| enough to know exactly what it does. It processes environment
| vars after a stage.
| delecti wrote:
| >Often times when people get creative with names, the meaning
| dies with them
|
| That's fine though. Anything you work on will inevitably
| develop a personality in your mind beyond what the name
| literally means, so what's the difference if the name is
| something like GAS (generic-acronym-service) or Fuel (GAS >
| gasoline > fuel).
|
| A persuasive dev at my last job tried to insist on non-
| acronym names for every new service, and 5 years on, I can
| still remember every proper name, but none of the acronyms.
| That, to me, is sign of a good name.
| jonny_eh wrote:
| > The article lists a few repos as examples of bad naming
| when the reality is, it's examples of miss-naming
|
| I'd assume everyone here could at least agree that naming is
| hard. I don't think the article was attempting to explain how
| to name, but instead point out one potential pitfall when
| naming.
| gabereiser wrote:
| Yes. Naming is hard, but it's easier when you aren't using
| pop culture as names for things. Shelob service only makes
| sense if you are a Hobbit.
| drewcoo wrote:
| This, exactly. Seemingly misnamed services are a sign of
| architectural decay. That sign is useful if you pay attention
| to it. If it's embarrassing to explain to new hires, just fix
| it!
| whatshisface wrote:
| In many environments you don't control the evolution of
| software. Unless the big boss does all the naming, then the
| people doing the naming can't stop other people from making
| AuthTokenValidator send change password emails and them
| eventually send marketing emails. ("Hey, this service already
| controls the noreply address...")
| gabereiser wrote:
| If you developed your services right. You'd have a
| notification service that does SMS,email,smokesignals...
|
| It's up to principal/staff engineers to make sure that the
| components of the system stay lean to its purpose. They
| should be able to say "oh, we need to send an email when
| this happens? Here's an email service we can use" that
| doesn't introduce feature creep into AuthTokenValidator.
|
| I get what you're saying but these little shortcuts (adding
| email sending in AuthTokenValidator) cause enormous tech
| debt later on when you scale.
| [deleted]
| sebastos wrote:
| This is what I'm getting at though. If you work inside a
| MANGA company or something, then I imagine your life is
| probably dominated by navigating a huge byzantine ecosystem
| of services with uptime demands and tons of legacy code.
| Presumably there's lots of $$ riding on evolving those
| systems incrementally. In this frothing, roiling context
| where the only constant is change, I can see how it will
| often make sense to expand components beyond their original
| scope. Ergo, your services should be named whimsically.
| Fine.
|
| But many software projects are. not. that. That's really
| all I'm getting at. This web service developer bubble
| annoys me because they never feel any onus to introduce
| themselves in their blogposts and caveat their opinionated
| recommendations with the context they're coming from. In my
| world of robotics, just making a random family of services
| with non-descript names is a bad idea. The services in the
| system should have roles, and if the temptation arises to
| add functionality beyond that role, it probably means you
| need to step back and do some thinking about why that
| happened.
|
| Also: I know you were just making a rhetorical point, but
| notice that your example is still clearly some web service
| that we're assumed to be running :)
| kuramitropolis wrote:
| >MANGA company
|
| I'm gonna close the Internet for today because you, sir,
| just won it
| theknocker wrote:
| jasonshaev wrote:
| The tone of your post is unnecessary and not helpful to your
| point. I don't agree with the authors point but I can say that
| without being insulting or snarky.
|
| In spite of that, when did "making a database product" count as
| not "hard?" Building a database isn't "real software
| engineering(tm)?" Since when was building "authorization
| microservices" easy? In the simplest case, sure. But
| authorization in general is a huge problem space and I don't
| understand calling that "bs." Active Directory would like a
| word...
| sebastos wrote:
| On the contrary, I assume making decentralized database
| products is very hard. And I don't doubt that authorization
| is a whole can of worms. My point is not that they're easy,
| but that they're the type of problems you are most likely to
| care about if you're building a web service.
|
| A web service. Not a moon rocket, or an MRI machine, or high
| frequency trading software, or computation fluid dynamics
| simulations, or a compiler, or a video processing pipeline,
| or a word processor, or a 3D game engine.
|
| So, just saying: When bloggers consider the headline
| "Software component names should be whimsical", I wish they'd
| spend a second to ask themselves whether their advice
| actually applies to any of the niche domains I mentioned, or
| if it's just a best practice for their fellow web service
| developers. Presently, there's a cultural trend that you
| don't have to bother with that step, and you can just write
| as if your audience is always the other web service people in
| the valley. To me, that gets very grating, and that's where
| the snark comes from.
| jasonshaev wrote:
| Asking the author to provide more context on what domain(s)
| their blog post is meant to apply to is a reasonable
| critique.
|
| However, consider whether your original post made that
| critique clear, or if it got lost amidst the other ...
| stuff. The first two lines, in particular, will immediately
| put some readers (myself included) on the defensive.
| Describing somebody's work as "some web service bs" is a
| bad start. And if your point had nothing to do with the
| "hardness" of the problems, only that those particular
| problems are most relevant to building web services, why
| not just say that? Instead of the "...somebody who works on
| some web service bs assumes that that's as hard as the
| world gets," bit.
| cjpearson wrote:
| When it comes to rockets, whimsical names seem to be much
| more popular. Most of them are named after mythical figures
| with SLS being a notable exception.
| amadeuspagel wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| > The throwaway comment about not using diagrams was truly
| baffling to me.
|
| Very bizarre ... also, why not BOTH a diagram and discription.
| bena wrote:
| Next he's going to tell us the proper way to do cache
| invalidation.
| robsws wrote:
| 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.
| noufalibrahim wrote:
| 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.
| RcouF1uZ4gsC wrote:
| 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 wrote:
| 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!
| daveslash wrote:
| 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 wrote:
| 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.
| walnutclosefarm wrote:
| 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 wrote:
| 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.
| vitiral wrote:
| 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.
| blackbrokkoli wrote:
| 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..
| nocman wrote:
| 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.
| electrondood wrote:
| 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.
| javajosh wrote:
| 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
| darylteo wrote:
| Like this? https://www.youtube.com/watch?v=y8OnoxKotPQ :D
| staccatomeasure wrote:
| 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=2...
| davelondon wrote:
| https://www.dropbox.com/s/amoz52ja8got5wq/navigation.png?dl=...
|
| :D
| ArrayBoundCheck wrote:
| What an awful article. I wish I can downvote
| jiggywiggy wrote:
| 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
| bob1029 wrote:
| 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).
| ary wrote:
| 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
|
| 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 wrote:
| 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.
| Davidbrcz wrote:
| 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),
| patric the starfish....
|
| It was awful to work with, please don't go that.
| pnut wrote:
| I'd be curious to hear thoughts from anyone with practical
| experience of urbit, considering their intentionally nonsensical
| naming choices.
| habitmelon wrote:
| 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.
| adhesive_wombat wrote:
| 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.
| MagnumOpus wrote:
| 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...
| speed_spread wrote:
| Going from cool felines to places you fall from or wreck your
| ship into is an interesting analogy for OS X evolution.
| Hnrobert42 wrote:
| 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 wrote:
| 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.
| papito wrote:
| 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".
| 0x457 wrote:
| Product family is Core iX, Xeon, Atom, Pentium X etc.
| Intel(r) Core(tm) 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.
| adhesive_wombat wrote:
| 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.
| labster wrote:
| 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.
| ubertaco wrote:
| 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.
| Nomentatus wrote:
| 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.
| ryandrake wrote:
| 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 wrote:
| 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.
| KronisLV wrote:
| "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
|
| Here's the video timestamp for the proposed solution:
| 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.
| shp0ngle wrote:
| 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 wrote:
| 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.
| deanjones wrote:
| Also variables.
| k__ wrote:
| 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.
| z3t4 wrote:
| In functional programming most variable names are single letters,
| except for function names, they are either name of spices or
| animal parts.
| jeroenvlek wrote:
| 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!)
| yuan43 wrote:
| 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.
| bcrosby95 wrote:
| Back in the day,one of my coworkers actually did this once. He
| built up a giant metaphor for the project in terms of
| EverQuest.
|
| Even though I played the game I was pretty lost in that
| codebase. People that didn't play had no idea what anything
| did.
| ThePadawan wrote:
| > 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.
| dzhiurgis wrote:
| Better be consistently boring than ever misleading
| badhombres wrote:
| But as products evolve, their boring names become
| misleading. At least with non-boring names you can re-
| define what they represent in your company.
| hbrn wrote:
| Isn't it even harder to re-define names in a company?
| There might be 3 people involved in re-definition, but it
| affects 15 people.
|
| How are we going to notify those 15? Do we even know who
| those 15 are? Are we going to create a weekly
| redefinition newsletter?
|
| I think in most cases new meaning deserves a new name.
| Everything else is just hacks.
|
| How hard is it to change a name is a actually a really
| good metric for a company. If a simple rename takes
| several days, multiple approvals, rounds of QA, and a
| scheduled release next quarter, then you probably need
| those hacks.
| badhombres wrote:
| I think that's very extreme. Products grow at a gradual
| pace. I don't think there are defining moments when a
| product no longer supports something, or is no longer
| used in a way that it was intended to.
|
| I would argue it's easier to maintain peoples
| understanding of a product since that will also be done
| gradually. It's not easy to update naming inside of a
| code base without potentially breaking software
| significantly or causing unknown bugs elsewhere. I think
| most software would fail the renaming test. It's also
| generally not worth the money and time needed to make
| that change.
| khazhoux wrote:
| Do products/components really evolve so much that the
| name frequently become outdated?
|
| Half the article is like, " _There was a component called
| YamlParser, which is now a browser-based stable-diffusion
| renderer!_ "
| version_five wrote:
| Look at IBM "Watson". It had evolved from an AI jeopardy
| and Q&A engine into basically whatever salespeople make
| up.
| badhombres wrote:
| Yep, enough that they need a caveat every time someone
| new is told of the product. It happens, and it's gotten
| worse due to Agile.
| ThePadawan wrote:
| I've worked on tools that were slightly misnamed after 6
| months, and completely misnamed after 2 years. At that
| point they were also usually just nearly useless due to
| feature bloat and/or lack of scalability, so deprecated
| or replaced with something better.
|
| They didn't change names, but their successors would get
| a new one.
| ThePadawan wrote:
| Terrific answer!
|
| No idea which way you're arguing though! ;)
| moduspol wrote:
| I remember how confused I was when I found out a program
| exists called "FileMaker". Curious how that name was chosen.
| ThePadawan wrote:
| I'm still split on which category Adobe (Macromedia)
| Dreamweaver falls into.
| strken wrote:
| 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.
| im3w1l wrote:
| I think a whimsical type name can have a sort of purpose.
| Sometimes a name goes from being descriptive to being
| prescriptive. It feels like a straightjacket, preventing you
| from adding code that would otherwise naturally fit there. In
| that case I think a whimsical name can be a good idea. Then
| later when the dust has settled, when you reach the top of the
| mountain and get a clear view of things, then you can revisit
| the name.
| lifthrasiir wrote:
| > Now, if a name is going to be easily changeable forever,
| please do make it descriptive. I'd much rather maintain code
| where the variables look like numCols and numRows than i and j.
| (Just, for the love of God, if you change the meaning, also
| change the name). But if a name is going to serve as, in any
| sense, an identifier, something that will point at a big
| complicated thing from many places far away, make it an opaque
| identifier.
|
| The author is very clear about this matter.
| kogus wrote:
| Reminds me of the classic "how to write unmaintainable code":
| https://cs.fit.edu/~kgallagher/Schtick/How%20To%20Write%20Un...
|
| Especially this bit: Bedazzling Names
| Choose variable names with irrelevant emotional connotation.
| e.g.: marypoppins = (superman + starship) / god;
| This confuses the reader because they have difficulty
| disassociating the emotional connotations of the words
| from the logic they're trying to think about.
| hulitu wrote:
| This thing is gold. But i think that he misunderstood his
| audience or the audience did not read till this "This essay
| is a joke! I apologise if anyone took this literally. "
|
| There are a lot of Google and Microsoft programs who
| implemented his "advice" (i don't use Apple).
| endtime wrote:
| I did this in an infosec class in undergrad 15 years ago,
| inspired by exactly this essay. The first part of the project
| was to write a program that password protected a file, and
| the second part was to try and break each other's programs,
| with full source code access. I think it helped discourage
| people from trying to deal with mine as opposed to other
| people's. (Also, several people correctly guessed that it was
| mine despite the code being nominally anonymous...)
| jgerrish wrote:
| Just in spite of this comment I'm going to name all my futures
| _:
|
| bitch_please
|
| I invite spirited debate on this change request.
|
| Is it an attempt to police the behavior of the async runtime?
| As a non-mainstream user of a minority language with pluggable
| runtimes, do I have the right to reappropriate this word?
|
| Perhaps we can develop a language standard for async priority
| variable prefixes and suffixes. Removing it from the domain of
| library convention to language feature.
|
| We currently utilize function parameters as the only input to
| functions, leaving a powerful source of information untapped on
| the left-hand-side._ Will this change speed up development, or
| more likely, introduce errors? Will advances in language
| development environments reduce that concern?
|
| How about: bitch_please, bitch_now, bitch_after_next_slice
|
| Note how the meaning of the variable changes with bitch_now? It
| feels more uncomfortable doesn't it? Less of a joke. Ignoring
| the runtime's own priorities and values changes this. But why
| is it less funny? What does that reveal about priorities and
| still-existing prejudices in LANG? Does that mean that the
| original use is also less funny in certain contexts, such as
| public spaces?
|
| Alright, change withdrawn, I was wrong.
|
| * This isn't an original joke, but it is further refined. * I
| could have been a good academic or scientist.
| blowski wrote:
| My 8 year old son names all variables after his friends.
| noworriesnate wrote:
| I was once tasked with extracting valuable IP from a legacy
| codebase where the developers had named all types after
| animals. So there was a SealService, a WalrusFactory, etc. etc.
| It was horrible and infuriating. They thought they were being
| cute, instead they just made everyone who ever looked at their
| code hate them with a passion.
| danielvaughn wrote:
| What about a whimsical emoji as a variable name? lol.
| giraffe_lady wrote:
| Probably not by itself but it isn't that fundamentally
| different from some language conventions allowing/preferring
| glyphs over words for certain meanings eg `string->int`
| rather than `stringToInt` or whatever.
| calvinmorrison wrote:
| i was wrong, this doesn't work in perl
| politician wrote:
| I reserve emoji for cases where the language's compiler fails
| to do type inference and forces me to create a temp variable.
| motohagiography wrote:
| 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.
___________________________________________________________________
(page generated 2022-09-13 23:01 UTC)