[HN Gopher] Names should be cute, not descriptive
___________________________________________________________________
Names should be cute, not descriptive
Author : dmarto
Score : 314 points
Date : 2023-01-10 04:30 UTC (18 hours ago)
(HTM) web link (ntietz.com)
(TXT) w3m dump (ntietz.com)
| eyelidlessness wrote:
| I still lament the time when a former team had to rename a
| service referencing a noble sea creature to its perfunctory
| backend purpose, and our corresponding service with a rhyming
| name referencing hair loss had to be renamed to reflect its
| unambitious web target.
| foxyv wrote:
| I usually do both. I'll have an easy to remember Code name
| followed by a descriptive name. This is to disambiguate the 700th
| TranslatingProxyLayer project. For example: ReliantRobin-
| DatabaseCleaner
|
| Now when I search for it in a wiki or documentation I can find it
| easily, but people still know what the heck it is.
| ryanmcbride wrote:
| Last company I'm worked for named all their services after Toy
| Story characters and no one knew what anything did. "So Woody
| talks to Buzz that lives on the client's server and then pushes
| the data to Pizza Planet where Sarge queues it up to Bopeep". I
| hated it
| jkingsbery wrote:
| > The world is boring enough as is. Let's add more whimsy and
| cuteness through our service and project names.
|
| This is a recipe for creating a wholly impenetrable language
| about your services. Which is easier for an outsider to
| understand:
|
| "I updated the code for how Batman writes to Goliath in Cair
| Paravel"
|
| "I updated the code for how the backend services write to the
| customer database in the billing application."
|
| > I don't want to be the one to advocate for delaying features so
| we can rename broadcast-service to broadcast-and-new-
| responsibility-service. That's going to be an unpleasant
| conversation with your product manager, for good reason: Because
| this never should have happened, and it's a waste of time to
| change the name.
|
| What seems to happen more often at the particular Large Company I
| work for is that not just responsibilities change, but
| fundamental assumptions underlying the architecture of a system
| change every few years. So rather than renaming a service, often
| a new system is put in place that reflects these new assumptions,
| and this new system will have a new name. The migration then
| isn't about the new name, it's about the new system, along with
| the new APIs and model of operation that comes with it. Yes,
| there are lots of examples of billing systems written 40 years
| ago in COBOL, but most software systems have a lifecycle on the
| order of 3-5 years.
| fedeb95 wrote:
| yes, piling up dust under the carpet could have a cute name. You
| don't want to pile it in the first place though
| dopidopHN wrote:
| Whatever, but just don't use starwars or Marvel names.
| bsima wrote:
| > Your friend Sam is still Sam, even if Sam gets new
| responsibilities and sheds old ones.
|
| Does Sam's last name happen to be Smith or Cooper or any of the
| other thousand of occupational surnames people use? Just
| curious..
| knorker wrote:
| Cute names are awful.
|
| What, you don't remember every Star Trek character? What, you
| can't spell every Greek philosopher?
|
| Really, you don't know which are star names and which are galaxy
| names?
|
| And then there's the reuse. Which project mayhem is this?
| btbuildem wrote:
| This is one of the hardest problems in software development, and
| with good reason. Naming things is how we get a handle on them,
| how we mark our understanding of them. It's a pivotal issue, in
| how it attaches our brain-maps to the problems we tackle.
|
| How many times, as a developer, have you paused and pondered what
| to name a new entity? I often find the difficulty of naming a
| thing is directly proportional to my depth of comprehension of
| that thing, what it does, and the context it lives in.
|
| With that in mind, I see naming-things-for-what-they-are as one
| winning strategy.
|
| Quoting from OP:
|
| > The problem comes in when there's a mismatch between
| responsibilities and names. Names are a way of expressing
| identity, while responsibilities are ephemeral: Your friend Sam
| is still Sam, even if Sam gets new responsibilities and sheds old
| ones.
|
| I find this a bit misleading, since Sam is a person with agency
| and a unique personality, and the things we name are, well,
| things, with specific purposes and raisons-d'etre.
|
| But! At the same time, OP identifies a key characteristic of
| things-that-persist -- scope creeps, features are added,
| responsibilities evolve. Naming a server "Sysyphus" may seem
| cheeky at first, but I'd argue that it's a better name than "Load
| Processing Server 2". We tend to antropomorphize things, that's
| one, but also - things happen over time, notable events, that
| create a timeline of stories which in turn build up into the
| coherent base of knowledge / familiarity / wisdom that ties teams
| together. Using "humanized" or "personalized" names pays off
| here, they help to glue these stories together and contribute to
| the institutional memory that builds up over time.
|
| In the end, I think both approaches are valid and have their
| place, we just have to use our judgement as to when to use which.
| surement wrote:
| > This is one of the hardest problems in software development
|
| and that is one of the worst fallacies in software development
|
| naming things is not hard, people regularly give things
| terrible abstract names because they act like it'll never be
| possible to rename it and then add a 3-4 word comment above
| describing what it does
|
| if they just named it what the comment says then they'd have a
| fine name
| secondcoming wrote:
| Giving things cutesy names is hardly inclusive behaviour,
| especially for those who don't speak English as a first language.
| beshrkayali wrote:
| The mistake the author is making is that indeed his friend Sam
| will still be Sam (even if he changes jobs) but he is a human
| that exists regardless of his function. Variable names' on the
| other hand only exist to serve a function, when the function is
| gone the names that refer to it should be gone too. If you have a
| ml-worker node and you no longer need an ml worker, you refactor
| the code to remove those. It's much easier to remove than to
| rename, and consistent mild refactoring ( or code massage if you
| will) means you're more likely to remember what lurks in the dark
| corners of your code base.
| godelski wrote:
| Cute names are human readable. Descriptive names are hard to
| search for and hard to say. They are often overloaded. Best are
| cute but descriptive acronyms. Your brain remembers cute more, so
| optimize for your brain.
| jfoster wrote:
| I can't prove anything, but I have a feeling that this article
| was intentionally written to be annoyingly wrong in order to
| generate engagement.
| AYBABTME wrote:
| How about making them descriptively memorable:
| - shifting-priorities-routing-service - indiscrete-
| secrets-vault - gdrp-user-immolator - knock-
| knock-whos-this-authn - canihaz-authz
|
| I don't buy the "can't rename services" arguments though. It's
| also hard to rename variables, modules and stuff. We do it. I'll
| tell the PM I need to rename this function if they want to know
| what I'm up to. How often does a service morph so much that it
| needs to fundamentally change its vaguely-descriptive-name?
| Realistically I don't think I've even seen this happen once.
| xeyownt wrote:
| The advantage of making cute is that you can also make them
| small.
|
| I would really hate using shifting-priorities-routing-service
| all over the place, in particular in combination with steady-
| allocating-routing-service.
|
| Between cute/descriptive, long/small, it all depends on how
| often/where/long these names are used.
| Tangurena2 wrote:
| I think the "can't rename it" applies to APIs. Some of the PDF
| functions have COS as part of their name. The original name of
| Acrobat was Carousel. COS stands for Carousel Object System.
| The first version of Acrobat was released in 1993.
| surement wrote:
| > I'll tell the PM I need to rename this function if they want
| to know what I'm up to.
|
| Why can't more engineers do this? in my experience people
| rarely ever question the product team and you can see this in
| the products you use all the time. PMs are not robots, they do
| things the way that seems best given the knowledge they have of
| the customer and the software, but engineers have more
| knowledge of the software and they need to communicate it when
| it's relevant instead of overcomplicating features by blindly
| shimmying in what product is asking for.
| Xorakios wrote:
| When the name is public-facing rather than internal, cute is
| better because it's better suited for trademarking.
| trynewideas wrote:
| There's a decent middle ground where the cute name is also
| descriptive, even if it's indirectly so.
|
| For instance, Grafana's stack is
|
| Logs
|
| Graphs
|
| Tracing
|
| Metrics
|
| so their services are
|
| Loki
|
| Grafana
|
| Tempo
|
| Mimir
|
| which also spells "LGTM".
|
| Of course, then they shipped "Phlare" because apparently they
| couldn't find a cute name for Profiling?
| rhacker wrote:
| > Your friend Sam is still Sam, even if Sam gets new
| responsibilities and sheds old ones.
|
| But that's just your perspective. At HogCorp Sam is the Senior
| Data Engineer. People that need data adjustments probably go to
| the Senior Data Engineer, whether that is Sam or not. If Sam
| becomes VP of Accounts and is no longer the Senior Data Engineer,
| people won't stop going to the Senior Data Engineer, but it won't
| be Sam anymore.
| joelthelion wrote:
| Mmm, you'd be surprised. If Sam becomes VP of Accounts, people
| will still try to go to him for their data engineering needs,
| unless he tells them off...
| imwillofficial wrote:
| Names should be descriptive. Cute names are an abysmal time sink.
| Oh what does the quark service do? Who knows? Are there are 3
| services named zoidburg? Oh well.
|
| Service name's are best when it roughly shares what it does.
| imwillofficial wrote:
| I worked on a service called the Bill Auditor Service. When
| people wanted to find out who, wait for it, audited the bills,
| they knew where to go.
|
| And sure we had some services where their name no longer
| reflected their purpose.
|
| Those were refactored and renamed when the time was right.
| jraph wrote:
| The more I read about this topic on HN, the more I have a strong
| opinion that I should not have a strong opinion on this.
|
| (I'm for cute AND descriptive though)
|
| (and somewhat not against anything, unless things too generic
| like "Web" or "Internet Explorer" for a browser or "File manager"
| for a file manager)
| pvsnp wrote:
| Don't do this. I see these names as just obvious ways to describe
| what things do like variables. I wouldn't want to be reading code
| like ``` beeblebrox = zaphod + trillian ``` similarly names of
| services in architecture diagram shouldn't be undecipherable
| (outside of perhaps ultra secret projects -- then maybe those
| agencies should have a name generator :) ). The cute names even
| if based on some theme get very old and the cultural context
| almost always gets lost once the company/team outgrows. Also it's
| a much easier to refactor away a new service if lets say you find
| yourself adding a completely unrelated feature to a service named
| "accounting" or something boring,whereas if you named it "hades"
| or something cutesy, you don't have any indicator whether the
| feature has outgrown. I've found it much easier to
| deprecate/sunset services and systems when they're obviously
| named too. One exception I'd say is when nicknames just arise and
| it becomes obvious to call it that. It's very rare and it
| happens. Borg at google is perhaps a good example here. It's so
| all encompassing that it's obvious what it means and calling it
| another name like "container orchestrator" or something similar
| perhaps doesn't have same gravitas. I think Microsoft had
| something called Autopilot which is even clearer but not it can
| be applied to many things.
| eckesicle wrote:
| I'm strongly in the camp of cute names. They are memorable
| identifiers, nothing more.
|
| Cutesy names are greppable, meaningful names are not.
| 'billingmurray' Vs 'account service'
|
| Giving meaning to a service through its name is also mostly
| nonsense, since no name will convey enough information about it's
| responsibilities for it to be meaningful anyway.
|
| Besides, all of the systems and services you use are either
| acronyms or cutesy names already. Docker, Linux, Unix, qwerty
| etc. They're just labels.
|
| We have Spotify, not music.com, and Amazon, not books.com.
| thenerdhead wrote:
| I work somewhere where naming is notoriously bad both cute and
| descriptive. If I could wave a magic wand about naming, I would
| wish that people put less time into thinking about naming. You
| get better names that way.
|
| A simple exercise in improv could even be applied. What's the
| first thing that comes to the top of your mind when you think of
| "X"? If majority of people say the same thing, you run with it
| because that's the most obvious one. Choose the obvious one.
| hawski wrote:
| I'm afraid it would be tmp and tmp2.
| desio wrote:
| Wish I read this before I named gonna my dog "Noise Maker".
| mnw21cam wrote:
| TBH, I don't care if your names are cute or descriptive, but for
| the love of God, can they please be Google-unique? I don't want
| to search for a particular software tool and end up getting loads
| of results about hamsters.
| kqr wrote:
| TFA is based on a false dichotomy. You can have both.
|
| At one of my latest workplaces, there was a system of loosely
| connected, branching event-driven processing nodes where the
| events accumulated additional data as they rippled through the
| system.
|
| In the code and UI, this was represented as "heroes", coming from
| "guilds", "embarking" on "quests", eventually meeting their
| "reaper". On their quests, they entered "locations" containing
| "pickpockets" that pulled things out of (and put things back
| into) the hero's "inventory".
|
| This cute-but-descriptive vocabulary really helped less technical
| people grasp how it all fit together -- even if it was a complete
| lie and gave the wrong picture of how the system worked under the
| hood.
|
| (In particular, it is a common misconception that the heroes are
| driving the action by choosing locations to go to, when in fact
| it is the locations (processing nodes) that pull heroes (event
| data) along. But that misunderstanding never caused a problem in
| the four-ish years I worked with the system.)
| Izkata wrote:
| Along similar lines, we had a hell of a time getting various
| product people to understand template strings for translations.
| Eventually I got the idea to just call them "madlibs" and all
| of them understood it immediately.
| noveltyaccount wrote:
| This is a great anecdote. I'm firmly on the "call things what
| they are" side of this debate, but this example shows a
| thorough domain design that was cleverly shifted to a narrative
| format. Impressive.
| Macha wrote:
| Brew tries this:
|
| You write software formulas (packaging scripts) into bottles
| (binary packages) in your Cellar (installed packages
| directory). Some software, such as GUI applications, uses
| casks, because casks are a different type of container. If you
| want a new source of packages, you add a tap.
|
| I would take packages, packaging scripts, package repository,
| binary packages and GUI packages any day over brew's attempt at
| cutesy terminology.
| kqr wrote:
| I think there could be a difference here: you're already
| familiar with the domain brew operates in.
|
| The system I'm speaking of were extensively used and
| configured by people who had no prior experience with event-
| driven, branching logic, nor any familiarity with the terms
| involved.
|
| You can still argue it would have been more efficient to
| teach them that domain first, then teach them this particular
| system for it. Maybe. I'm saying as far as I can tell, there
| was no drawback to the cutesy terminology for the intended
| users (nor for developers other than in isolated cases) and
| it seems to me they learned quicker with that framing than
| without it.
| Macha wrote:
| I'm not sure assuming people are familiar with the process
| of alchohol brewing is any better.
| grahar64 wrote:
| Great idea!
| gwhl wrote:
| This describes absolutely nothing to me. It just confuses and
| excludes me. Then if and when I understand what it means I then
| have constantly translate mentally between the cute-yet-
| infuriating names and their actual meaning in the context.
| Towaway69 wrote:
| My approach is cute or funny names based on abbreviations, e.g.:
|
| - trump - totally reversible universal manipulation protocol
|
| - Biden - booked Internet device expense network
|
| That way a cute name has a meaning. Additionally one can change
| the abbreviation if the purpose changes!
| xtiansimon wrote:
| Funny trifle.
|
| I too like cute names at high levels of abstraction, because
| descriptions or explanations shouldn't clash with the named bits
| --particularly in documentation.
|
| But when a named thing doesn't escape the code files, then it has
| to be descriptive. My projects take too long, and coming back to
| a too cute name is a PITA.
|
| The exception is I use verb+cute name for command line script
| names.
|
| Naming is hard, but also fun.
| tremon wrote:
| My thoughts exactly. Cute names are identities: you apply them
| to things that are unique and where the purpose is malleable.
| Functional names are descriptions: they capture the thing's
| purpose, not its identity.
| spullara wrote:
| When I worked at Twitter many services have bird names and some
| have descriptive names. The descriptive names are far better. Who
| wants to remember the user service is Gizmoduck?
|
| Also, I don't know where this guy works that a service changes
| what it does over time.
| sixstringtheory wrote:
| The renaming point is actually the great point in this article
| IMO. But this just tells me that languages, platforms, frameworks
| and editors need to improve so that renaming things is easier. Or
| that people need to learn how to use grep/sed better (ETA: and
| use monorepos)...
|
| But this:
|
| > they're no fun
|
| > it won't be _fun_
|
| is the bane of my existence as someone who tries to get shit
| done. If this is the lens through which you view software
| development, and I have to work with you at my job, I literally
| hate you.
| janef0421 wrote:
| I think this is probably two far to one side. It is true that
| naming something purely descriptively may lead to misconceptions
| as its function evolves, but a "cute" name doesn't do anything to
| inform someone what it is. I would argue that best name has some
| semantic connection to the function, but is also somewhat
| abstracted; This allows it to be informative while accommodating
| evolution.
| ptr wrote:
| Since services are basically modules in monoliths, does that mean
| that we should have cute names for those as well?
| stared wrote:
| Let's go further:
|
| Function (and class) names should be cute, not descriptive. It is
| impossible to predict how these evolve and change their names.
| devnullbrain wrote:
| The mirror to this argument is that company names should also
| be descriptive. Goodbye Amazon, hello OnlineBookStore.
| stared wrote:
| There is plenty of successful companies with descriptive
| names. Facebook, IBM, BMW (Bayerische Motoren Werke),
| Grammarly, Duolingo, OpenAI, etc, etc.
|
| Personally, I prefer this approach. When a company gets big,
| it does not matter. If something is small, at least I get a f
| ---ing clue what it does (and it is easier to memorize).
| lemper wrote:
| nah, i'd stick with boring law firm names. people come and go and
| i don't want to inherit a project from john doe from 5 years ago
| that used a really obscure reference to gorean lore or some other
| "cute" names.
| tastysandwich wrote:
| Imagine starting at a new company and you view a big diagram of
| all the services. "Flipper connects to klunker, which has a
| database called plomb. There's an arrow going from gonky all the
| way down to zippydoo, which generates a report that gets handled
| by fogle. And all this is orchestrated by butt".
|
| I also like descriptive names because they help me fend off
| service bloat. "Sorry, it doesn't make sense to add bespoke
| client integration to report-generator. But we can make a new
| service which takes those reports and sends them to ABC Corp if
| you want."
| bryanrasmussen wrote:
| so are the names master and slave originally meant to be cute or
| descriptive, and how did that work out for everyone?
| ChrisArchitect wrote:
| Naming is one of the hardest things in computer science of
| course....
|
| ..but also one of the most fun!
| germanfella wrote:
| I made an account on HN because this is the worst post I have
| ever read here.
|
| NO!!!! DON'T USE CUTE NAMES!!!
|
| I am currently working with a big company for my apps and it is
| full of cute names which are the biggest problem for me. To
| launch an app you have first to integrate the Zaamla-Service into
| your IDE. Then just patch things up with Pimble, upload the
| signed HIMA-Package into the Katala and activate after that Zanik
| on the Bremmis platform to include the Mumana-Service to
| distribute the app.
|
| What? It doesn't work? That's because you didn't integrate the
| Jonhson-Rod stupid? How is it supposed to work without the
| Johnson-Rod? Are you even a real programmer?
| gilbetron wrote:
| Right? It's like having to "google" to find out how to use your
| "apple" to interface with "postgres" that's running on "linux"!
| It should be "global-web-searcher-1", "computer-vendor-17",
| "database-18" and "open-source-operating-system-derived-from-
| another-operating-system"!
| danparsonson wrote:
| Exactly! That's why I always advocate giving every monitor in
| an office its own unique name (mine is Moe!) and every
| keyboard, chair, desk, etc. Who wants to use those stuffy
| descriptive generic names??
|
| Obviously trademarks and other product names are more useful
| if they're unique; Google, Apple, etc. are not components of
| a system, they're products. It's like getting your car fixed
| - they don't tell you the Jane and the two front Turnipheads
| need replacing, now do they?
| gilbetron wrote:
| So you name your keyboard "character-event-generator-1",
| your chair "butt-and-back-holder-1" and your desk "four-
| stick-and-board-to-hold-items"?
| Gigachad wrote:
| Doesn't sound like that would be any easier with different
| names
| pprotas wrote:
| I'm sorry but I just have to link this classic video, this
| comment reminds me of it: https://youtu.be/y8OnoxKotPQ
| nextlevelwizard wrote:
| Sounds more like architectural/tooling problem.
|
| We use pretty much random names for our servers and other
| hardware, but all of that is abstracted so during normal
| operation you don't even know what _thing_ you are using unless
| you want to for some reason.
|
| I am not really for or against using names instead of numbers
| or whatever, because I should never even need to care if things
| are done right.
| 28304283409234 wrote:
| I heard that Ifthingsaredoneright is a really nice planet to
| visit one day.
| EFreethought wrote:
| It's better than being on planet
| someonewasintentionallystupid.
| jeroenhd wrote:
| Would this be easier if you needed to integrate with user-
| provider-service, timestamp-conversion-service, image-storage-
| service (which also stores videos these days, though HEIFF and
| h.265 has obviously been moved to iOS-image-storage-service so
| customers can be billed for the special software that requires
| patents) to upload a signed SecuredApplicationPackage file to
| InternalExternalSoftwareManager so that it can be included in
| the application_distributor next time ReleaseMgr decides to
| update its endpoints?
|
| What, you forgot to integrate with the
| SecondaryDataValidationService? How is it supposed to work
| without SecondaryDataValidationService? Are you even a real
| programmer?
|
| God forbid you use the old DataValidationService or
| ReplacementDataValidationService, those have been deprecated
| for years. And you don't want to make a fool of yourself by
| using ImageStore instead of image-storage-service, ImageStore
| is clearly for operating system images not pictures! And what
| are you doing touching IntermediateDataLayer? That's only for
| enterprise customers, shouldn't that be obvious? It'd like
| adding a dependency to CachingLayerV2 to a ServerSideSoftware
| deployment package, simply ridiculous!
|
| If you have a forest of microservices to browse through, it
| doesn't matter if they're named after pokemon or if some
| engineer came up with a descriptive name. You need a guide
| either way, because half of the services that sound like they
| may be relevant do something completely irrelevant or have been
| put in maintenance only mode years ago anyway.
| Draiken wrote:
| Not only that, but half of those services would become
| acronyms very quickly.
|
| Would this be easier if you needed to integrate with UPS,
| TCS, ISS (which also stores videos these days, though HEIFF
| and h.265 has obviously been moved to iOS-ISS so customers
| can be billed for the special software that requires patents)
| to upload a signed SAP file to IESM so that it can be
| included in the AD next time RM decides to update its
| endpoints?
| xeyownt wrote:
| Couldn't have said it better.
|
| Overall, common sense should be the rule, not "always
| descriptive / always cute".
| beckingz wrote:
| The thing about common sense is that sense isn't common.
|
| Also, more accurately, the environmental information used
| for our common sense naming changes out from under us.
| eYrKEC2 wrote:
| What if this is survivor-bias?
|
| The only services that continue to live have memorable,
| marketable names that stick in people's heads and make them
| want to say the service because of the cheap dopamine hit they
| get from being "in-the-know".
|
| The ones that no longer exist were purely utilitarian, but
| since their identity was pure functionality they are only known
| as their bugs and quickly despised?
|
| ---
|
| I don't know if this is true. Just asking the question.
| andy_ppp wrote:
| Why not take this to its logical conclusion and name modules,
| functions and variables cute names too. You need to understand
| the program and the code could be lying to you with its naming so
| why bother to name them at all. Start with Pokemon characters,
| atomic elements, geographical features etc. The possibilities are
| endless! This naming strategy can also save time when refactoring
| because you can change the meaning of a variable (for example)
| without having to rename it everywhere!
| surement wrote:
| just name things with single letters and when you run out you
| can use double letters etc.
|
| you'll be so fast at writing code a promotion is sure to follow
| contravariant wrote:
| Contrarian take:
|
| If your code is unreadable with single letter variable names
| your comments aren't clear enough. Case in point:
| Mathematics.
| nirui wrote:
| I think "either this or that" type of thinking is unfit for the
| topic. A better strategy is to setup a priority: making the name
| descriptive should be very close to the top, and making it also
| cute should be somewhere down the line.
|
| Also, cute is really subjective. Personally I think "Continuous
| Integration/Continuous Delivery" is cute and "cli-anal-stats" is
| very cute, even through you might not think of it the same. The
| advantage of descriptive names is that it's more recognizable,
| you read the name, you knew what they do, and that's cute for me.
| geysersam wrote:
| This problem is quite interesting from a theoretical point of
| view.
|
| How to structure a program to be less dependent on its name?
|
| Would it be possible to have a single source of truth for names?
| So that if you want to change a name, that's a single line
| commit.
|
| Problem is, if the name is dynamic we'll have to refer to the
| name using another name.
| cglong wrote:
| I was on a team that used cute names. It was fun during the
| development cycle, but super annoying when you're dealing with an
| outage. Not only did we constantly get misassigned tickets, but
| it can be difficult in that moment to remember if you're supposed
| to engage the Dynamic Pterodactyls or the Hopping Hippos.
| styluss wrote:
| having worked in a company where project were named after marine
| life, I changed my mind, no cute names.
| lamontcg wrote:
| This is a good example of negativity bias.
|
| So you have to remember all these random names matched up with
| their functions, memorizing all of it, because that is far better
| than one of them being misnamed and having to remember that the
| broadcast-service does something else.
| hcarvalhoalves wrote:
| Nobody today would believe naming classes after greek gods or
| anime is a good idea, but for some reason it's okay for
| (micro)services.
|
| I've worked at places that do this, I think it's a bad idea.
|
| Not having descriptive names turns architecture discussions into
| bikeshedding ("I think we should create a new service named
| Pikachu instead of extending the scope of the Naturo service").
| dctoedt wrote:
| When U.S. law applies, trademark lawyers urge companies to find
| "suggestive" names -- requiring insight to realize "ah, _that 's_
| what this is!" -- as the "sweet spot" to get the most bang for
| the buck in marketing while still being legally-protectable.
| (Examples: Coppertone for suntan lotion; Greyhound for bus-
| transportation services; Energizer for batteries.)
|
| "Merely descriptive" marks _can 't_ be protected legally without
| proof that they've acquired "secondary meaning," e.g., through
| widespread advertising, going viral, etc.
|
| "Coined" or "fanciful" marks such as Reebok and Kodak, and
| "arbitrary" marks such as Lotus for software, are protectable,
| but they don't do much good in advertising, at least not
| initially, because customers don't know what product or service
| is.
|
| Self-cite: https://www.oncontracts.com/startup-
| law/#Trademarks_look_for...
|
| Usual disclaimer: I'm a lawyer but not _your_ lawyer.
| tgv wrote:
| If your problem is that names are too descriptive, give your
| services a number. Because your naming fun will run out of steam,
| and it'll become cringy as heck when some engineer who thinks
| (s)he's funny assigns a cute name to a service that makes the
| rest of the company gag. It's quirkiness for the sake of showing
| off, not to solve a problem.
| ram_rar wrote:
| Hard disagree. Especially for backend/infra or any cross team
| usage. One of my previous company widely popular for crunching
| logs had starwars esque names for various services and Kubernetes
| infra. It was a terrible decision, since it lead to another layer
| of abstraction to know what those meant in the context, also when
| employees churn, reorgs happen, a lot of this info gets lost into
| oblivion.
| ashton314 wrote:
| I've liked "cute" names that are related to their original
| responsibility in some way. E.g. we had a messaging service
| called "McFeely" after Mr. McFeely's Speedy Delivery Service from
| Mr. Roger's Neighborhood.
|
| When someone gets onboarded, they'll encounter these names and
| will have to ask. It's a short anecdote, and it sticks. I'm
| personally a fan of these, as long as the stretch isn't _too_
| far. Themes around names can be nice, too. (As with the above,
| Mr. Roger 's Neighborhood.)
| doctor_eval wrote:
| Yeah I nearly posted the same thing. We had a service called
| "petal" which did settlement - "settle petal" is a bit of
| Australian slang.
| themoonisachees wrote:
| As a sysadmin who deals with several clients with different
| naming conventions wrt server hostnames, i feel like both schools
| annoy me;
|
| for example one of our clients has FRPRTFSQL02, where fr is
| france, pr is production, tf is the app this server relates to,
| sql is the type of service this hosts, and 02 is sequential, so
| for an sql server this means it's most likely a ro replica.
|
| On the other hand, another client names their servers just
| "montana", "barcelone" or "morroco" with no relation to the
| geographic aspect of the name.
|
| In both cases, and maybe this is just because i work and exist in
| this wierd liminal space where i care about the server but not
| what's on it (if i end up caring what's on it, i find out what i
| care about by looking at logs etc, not the name) so both ends of
| the spectrum tell me absolutely nothing about the machine and
| it's just an annoyance to remember them. I find cute names easier
| to remember and tell my coworkers about, for what that's worth.
|
| On my own infra, i name my servers with simple descriptive names,
| like "matrix" is hosting matrix and "play" is hosting game
| servers, but i don't have the infrastructure for that to be a
| problem (ie i do not have 2 copies of anything running) so i can
| afford to do it, but i know it's not a good solution.
| bobbiechen wrote:
| I'll put in a vote in favor of cute names, in the specific
| scenario of talking (out loud) about specific services - it's
| less clunky and personally, way easier to correctly parse cute
| names than common-words-which-may-combine-into-a-service-name.
|
| To take some examples from public cloud:
|
| "We can put that data in Cloud Storage Archive" vs. "We can put
| that data in Glacier"
|
| "This service runs as a function in Azure Functions" vs. "This
| service runs as a Lambda function"
|
| "Use the standard machine image" vs. "Use the standard AMI"
|
| On the other hand, I did work on a system where all the services
| were spaceship names, and that was a nightmare to onboard people
| onto... echoes of https://www.youtube.com/watch?v=y8OnoxKotPQ ,
| especially as one was named Galactica
| pbnsh wrote:
| Was that company by any chance founded by a rick roll sent via
| an api/sms and has 4 dots in it's logo?
| abram wrote:
| I read this article and was surprised it was written yesterday
| because I could have sworn I read it a few months ago. Turns out
| I was remembering a post by a different author making the same
| arguments, discussed on HN here:
| https://news.ycombinator.com/item?id=32807969
| kstenerud wrote:
| Sorry, no. Service naming is essentially the same argument as
| module or class naming. We've already had that argument and
| descriptive names are king for reasons that have been explained
| to death over the past decades. Could you imaging going through
| an unknown codebase and finding that all of the names are
| "Scooby" and "Rumplestiltskin" instead of "RenderPipeline" and
| "UserInput"?
|
| If your service starts taking on responsibilities that render the
| name non-descriptive, then it's likely taking on responsibilities
| that it shouldn't, and you need to have a talk with your
| architect, same as you would with an entirely local app.
| cbeach wrote:
| I'm at a mid size company that is currently moving away from cute
| names onto meaningful names.
|
| I'm glad we're going in this direction as the onboarding process
| was painful, trying to piece together so many arbitrary facts,
| and I'm reminded of this pain every time someone joins and I have
| to talk them through architecture diagrams.
|
| Using meaningful names will force us to maintain microservices
| that honour the single responsibility principle.
|
| Scope creep is a form of tech debt, which must be repaid as
| opposed to being tacitly endorsed by naming services with
| mutability in mind.
| Hani1337 wrote:
| Why not both? Do it like counterstrike maps with their gamemode
| prefix de_ cs_ kz_ surf_
|
| host_dandelion01, client_pollen01, merger_fusion,
| compiler_compost_v1, etc
| erikpukinskis wrote:
| There's some history here people are missing.
|
| Back in the day we used cutesy names for _boxes_ , and we did it
| for good reason:
|
| Back then, before cloud services, when you were building out an
| application, you would build one computer, load it up with some
| services, and then when that one started performing poorly you'd
| add another computer and move some of the services off.
|
| You would frequently rebalance which services went on which box,
| in order to maximize performance.
|
| But these boxes weren't services themselves, they were just the
| machine some set of services happened to run on.
|
| So we gave them cute names because the hardware was largely
| meaningless. They had no inherent purpose, so we named them
| Athena, Zeus, etc so we had something to remember.
|
| These names were largely not used for the services. Maybe you did
| have your FTP service on Athena, and maybe that was the only
| service on there. You still served it from ftp.techdazzle.com or
| whatever.
|
| I feel like people just ported this concept forward into the
| microservices realm because it's fun, even though it doesn't
| really make as much sense in a cloud environment.
| scruple wrote:
| My first role had machines like: ob-la-di for the reporting
| services server, ob-la-da for the nightly build server, etc. I
| always hated it. In aggregate the services on these servers
| belonged together. The sysadmin was just extremely casual about
| his role and thought it was funny and cute. I eventually got
| sick of going to the wrong server all of the time and mapped
| them more logically in my hosts file. It's not like he couldn't
| have done this originally or eventually, but well into the
| 2010s he was using song titles for server names.
| athenot wrote:
| A funny example of this can be found by looking for nameserver
| entries for vatican.va. An apostle and arch-angel for the
| Vatican, mixed with an Egyptian god and apocryphal character
| for the Roma exchange they partner with.
| vatican.va. 3600 IN NS john.vatican.va. vatican.va.
| 3600 IN NS michael.vatican.va. vatican.va. 3600 IN NS
| seth.namex.it. vatican.va. 3600 IN NS osiris.namex.it.
| nix0n wrote:
| I agree that this makes sense for boxes.
|
| > we named them Athena, Zeus, etc
|
| The bonus of this kind of theming is that if someone mentions a
| Greek god you know they probably mean a box.
|
| One reason this makes more sense for boxes, is that a box will
| have features and responsibilities taken away more than a
| program or service will.
|
| If a service is named according to what it originally did, even
| though it took on additional responsibilities, that's fine.
| bfung wrote:
| Even more fundamental, if you had multiple computers and needed
| to network them up, they required a name to be referenced by.
| Computers on the same network ended up with names from a common
| theme.
| plank wrote:
| Ah, memories. Remember the time a new set of boxes came, and my
| and a collegue came up with a bunch of names. Being a physics
| department, the new names had to fit in the existing name
| convention with names like Gauss and Planck. And yes, used that
| to get the latter one placed on my desk (new shiny powerpc with
| colour screen!) instead of an old Atari;-)
| AtlasBarfed wrote:
| ... that implies all your services already were HTTP-separated
| or some other swappable network invocation besides direct calls
| ...
|
| Which means... you were microservicing before microservices
| were a thing?
|
| If not, do you care to share how you abstracted your service
| invocations so they could fluidly go from inter-box comms to
| separated boxes?
| marcosdumay wrote:
| Network services were port-separated since the internet was a
| thing. (A bit earlier, but ports had different names.)
| franga2000 wrote:
| The vast majority of IPC already used sockets decades ago, so
| it was easy to split a composition of services across
| multiple machines (just change the config from unix domain-
| to network sockets). Anything that ran commands to do things
| could be wrapped in ssh (for example, that's how I offloaded
| image processing for a sharing site).
|
| Two layers of DNS records solve the addressing issue: each
| box gets a static codename with an A record and each service
| gets a descriptive name with a CNAME record pointing at the
| box it's on.
|
| When you move a service, change the CNAME to point to the new
| box. If you have full box replicas/backups, you can also
| switch the box name or reroute at the IP level. Preferably
| you're running your own DNS and can issue a flush command to
| your entire fleet so you're not stuck waiting for
| propagation.
| jagged-chisel wrote:
| > Names are hard to change.
|
| Brands are hard to change. Is your thing a brand for your
| company? Probably.
|
| You need your "cute" name (branding, differentiation, trademark)
| and a descriptive name. "Marmaray" tells the reader nothing.
| "Marmaray Tunnel Service" is more informative. Of course, once
| your fellow conversants become accustomed to the vocabulary,
| "Marmaray" is going to save time during speaking. Until then,
| you're just going to have to be aware that you'll need to educate
| folks along the way.
|
| I find it outright pretentious when I hear anyone using strings
| of "cute" names with no attempt at actually explaining the stack.
| throw__away7391 wrote:
| If you're going to do this, why not also do it for classes,
| function, and variables?
|
| The the reasons you wouldn't do that are also reasons you
| shouldn't do it for services.
|
| A product might have a code and/or marketing name, but that's a
| different story. You shouldn't give cute names to services or
| other internal components pieces of products. Every time this
| comes up I remember that KRAZAM Microservices video, "because
| Bingo knows everyone's name-o". (https://youtu.be/y8OnoxKotPQ)
|
| A random aside, definitely the very worst name you can give any
| product is "Atlas". I once worked on a product called "Atlas"
| that also used a library and an unrelated external API also
| called "Atlas".
| jakelazaroff wrote:
| _> If you 're going to do this, why not also do it for classes,
| function, and variables?_
|
| Because those are easy to change. Service names inevitably get
| strewn across who knows how many other services and pieces of
| infrastructure.
| zffr wrote:
| Are they easy to change? Consider the scenario of a SDK
| provided to external developers (ex: UIKit). Any symbols made
| to be public API cannot be changed between releases cannot be
| changed without breaking clients.
|
| It's true the SDK authors can deprecate and remove symbols,
| but this is not always easy to do, and sometimes can take
| several months or years to do.
| jakelazaroff wrote:
| Broadly, I'd say there are three categories, in ascending
| order of change difficulty:
|
| 1. Private code. Renaming things is easy, since you only
| have to worry about your own references.
|
| 2. Libraries with no external dependencies. Changing
| symbols in the public API can break clients, but clients
| can always not upgrade and everything will continue working
| exactly as before.
|
| 3. Libraries with external dependencies, like on an
| operating system (e.g. UIKit) or a web service. Changing
| names will break clients that don't also upgrade. IMO this
| doesn't really count as changing the name in _code_ , per
| se -- the issue isn't that the downstream code is coupled
| to the library code, per se, but the underlying
| infrastructure.
| throw__away7391 wrote:
| It sounds like your deployment and provisioning
| infrastructure is sub-par. Why would you shove unrelated
| functionality into the same service? Especially to the point
| where you can't even choose a descriptive name for said
| service.
| jakelazaroff wrote:
| _> It sounds like your deployment and provisioning
| infrastructure is sub-par._
|
| If you want to add supporting details to that -- like, any
| at all -- then we can have a discussion. The rest of your
| comment doesn't actually relate to anything I said.
| throw__away7391 wrote:
| If you need to choose a random name up front because you
| can't predict what the service might be doing someday,
| possibly you have a poor architecture--services should
| follow scaling and data boundaries, both of which lock
| you into a specific (namable) scope, or if we are more
| charitable to you and blame devops instead it takes too
| much effort to deploy new services, there too many manual
| steps involved, or you're doing things like hard-coding
| configuration or references between services, leaving you
| to shove unrelated functionality into the same services
| out of expediency.
|
| You could make the exact arguments you're making about
| classes or modules. You say these are easy to change, but
| when your infrastructure is set up correctly services are
| also easy to change, it is all just code. If your
| infrastructure is not set up to allow services to be
| changed easily or I think you should stick to a
| monolithic architecture, because trying to do development
| in an infrastructure-constrained environment is a
| nightmare.
|
| I have to admit initially it didn't cross my mind that
| this could just be bad service design, Service boundaries
| chosen poorly not because infrastructure makes changes
| difficult but because developers just didn't know or plan
| properly, but now that I think about it that is probably
| the more common case and in fact is another good argument
| for descriptive names--e.g. hopefully it would give one
| pause if they decided to add some order processing code
| into a service named "delivery notification".
| jakelazaroff wrote:
| Here's where you lose me:
|
| _> You say these are easy to change, but when your
| infrastructure is set up correctly services are also easy
| to change, it is all just code._
|
| Unless you have extremely simple infrastructure, it's
| very much not "all just code": it's programs that are
| running on different machines that don't intrinsically
| know about each other.
|
| Then it becomes a coordination problem. For example, if
| service B calls service A and you want to change the
| hostname of service A, you need to first make sure that
| service A will respond to the new hostname, and then that
| your discovery layer knows about that change _before_
| service B -- and also that it still handles the old name
| correctly until service B has been updated.
|
| "Oh, but I have all my infrastructure in
| [Terraform/Cloudformation/Pulumi/etc], that's not a
| problem for me." First of all, there are a ton of reasons
| things might slip through the cracks. Maybe you're
| migrating from one system to another, or maybe some
| dependency doesn't have great support, etc. But second of
| all, infrastructure is stateful and things can go wrong.
| If your change fails halfway through for some reason, and
| only some pieces are aware of the new name, are you
| _sure_ your system is consistent?
|
| Code, on the other hand, _is_ just code -- changes are
| atomic and self-contained. If I change a function name, I
| know that everything that could possibly use that
| function is contained within my codebase. When I deploy,
| it 's either using the new name or not -- and it doesn't
| matter if half of my servers have different names for the
| function, because they don't interfere with each other.
|
| The one exception to this is public APIs, which are
| difficult to change without breaking downstream
| consumers. But consumers can always choose not to upgrade
| their version of the library. And when they can't -- when
| it's a proxy for an external dependency, like a web
| service -- the issue isn't the name in the _code_ , but
| the name in the infrastructure.
| ubercow13 wrote:
| It's not always possible to know upfront the perfect
| architecture of your whole system. Not every business
| domain is as trivial as 'delivery notification'.
| throw__away7391 wrote:
| If you change "not always" to "almost never", I'd agree
| with you. I still think you can give your services
| descriptive names. Even non-trivial domains can have a
| name.
|
| Anyone building a monolithic application is using
| packages or sub-modules to organize their code. While
| basically all monolithic applications have some kind of
| product or code name, I have never once seen anyone give
| a sub-module a weird cute name. But deploy that same code
| into a container and suddenly people want to start
| calling it "Skywalker" or "Cthulhu".
|
| If you are using Domain Driven Design (or something
| similar, hopefully you're using some kind of
| methodology), naming the domain is one of the very first
| steps. You should be able to come up with a name for a
| service domain that is descriptive enough such that a
| major change to the name would also mean it was a
| different service.
|
| What I am seeing is all the pro-cute names arguments
| against this seems to be describing a scenario where
| you're just sort of randomly adding code to services out
| of convenience. This is very much putting the cart before
| the horse and I don't really know what else to say beside
| that if you're doing that I think having cute names is
| probably the least of your problems, particularly when
| you're talking about long term maintenance of this
| software. These names do eventually have to be described
| to someone, and if you can give a coherent description of
| what the "Birdman" service does, you should be able to
| give it a good name.
|
| First and foremost, services should own their own data,
| therefore it necessarily follows that service boundaries
| will follow data/domain boundaries. The second most
| important consideration for service boundaries is scaling
| points, which in turn directs service boundaries to
| follow specific interactions. I almost never break up
| services unless they cross one of these two lines, and
| taken together they give a scope of data and activity for
| any service that is enough to give it a descriptive name.
| mlyle wrote:
| > Why would you shove unrelated functionality into the same
| service?
|
| Because you notice that Broadcast-Service happens to
| already know some other important stuff about all the
| enregistered clients. And perhaps answering queries about
| that or naming ends up becoming its most important job...
| even though it was originally just a simple broadcast
| service.
|
| Then, later, you end up not even using the broadcast
| functionality.
|
| Code drifts and changes. Top level names are more likely to
| be lies than variable or function names, because the latter
| are easy to change.
| imwillofficial wrote:
| Then change the service name.
|
| "The name doesn't reflect its function anymore" is not a
| good case for "let's name it some random thing", and
| certainly not a good case for "let's arbitrarily give
| descriptive names for some resources over others"
| mlyle wrote:
| It's very difficult to change service names, given that
| you have a large population of people conditioned to say
| the name and lots of documentation artifacts, other code,
| etc.
|
| "Broadcast message service" is, as the author points out,
| way too generic and also too long to be used freely.
| "Scattershot" rolls off the tongue and won't be
| _completely_ wrong if functionality changes. And
| hopefully we have a small enough quorum of services that
| we don 't drown in jargon.
| marcosdumay wrote:
| > Because you notice that Broadcast-Service happens to
| already know some other important stuff about all the
| enregistered clients.
|
| Looks like you are trying to get a complete separation of
| concerns. That's a good practice when modularizing code,
| but it's not unambiguously good for services, because
| composing services come with added cost.
|
| On practice that means that if those pieces of
| information are really important, there will probably
| exist many services that read them, and trying to reduce
| that to a single one will break many good qualities your
| software has elsewhere. Your service having a clear
| purpose is one of those qualities.
| wvenable wrote:
| In my opinion, one of the top criteria for a good developer is
| that they don't fear making changes. If a function has changed
| purposed, a good programmer will rename that function even if
| it's across hundreds of files.
|
| A poor programmer will see that as wasted effort and not do it.
|
| From my experience working with a good infrastructure team,
| good system administrators do the same sort of thing. It's easy
| to not change names but in 10 years you have no idea what
| you're looking at. Our team is constantly moving stuff around
| and renaming things when it makes sense to do it.
| banku_brougham wrote:
| To me the most painful style of wasted effort is that of
| renaming an entity and all of the connection points to other
| services, and documentation, wikis, slack channel names,
| email lists, etc. because the name is causing cognitive
| dissonance.
| wvenable wrote:
| That's the trade off. You have to decide whether or not
| it's worth it. But if you never do it, then you end up a
| with a system where nothing means what it says and that's
| awful.
|
| I feel the best time to rename something is as early in the
| development process as possible. Because the longer
| something is wrong the more entrenched it becomes.
| szundi wrote:
| If you plan to exit in 2 years and you don't give a sh*t
| after that, sounds like a plan!
| unbalancedevh wrote:
| > the very worst name you can give any product is "Atlas"
|
| I always thought the worst name was "Next Generation ...",
| which quickly becomes kind of silly when it's time for the
| revision after that.
| TylerLives wrote:
| The difference is that a service might do many things, while
| functions and variables usually have smaller purpose.
| throw__away7391 wrote:
| Surely though in any case either there is some unified theme
| or purpose for a service or you are building a monolithic
| application which can just have the same name as the product.
|
| If you are putting random functions into a service to the
| point where you can't even pick a descriptive name, that
| sounds like you've got bigger problems.
| jxramos wrote:
| so true, names in different contexts have different needs. For
| internal stuff comprehension is king. I see this show up in
| front end and backend stuff frequently, especially in the
| microcosm of a console app in python where argparser can
| specify the `dest`, or internal name of a command line option.
| All my bool options get dest=is_xxx prefixes. Using more
| verbose names under dest is good too.
| jacknews wrote:
| LOL, is this sarcasm?
|
| Perhaps we should copy science and maths and name services after
| their developers: chet-obagdu-braithwaite server
| peyton-garcia endpoint murata-checkov service
| somerstein API
|
| etc. LOL.
| deafpolygon wrote:
| Says names should be cute. Does not offer cute name in article.
| Lapsa wrote:
| what a weird article... am I blind? where's an example of such
| "cute naming"? am I supposed to name everything AYAYA now?
| concise names aligned to business domain are worse because the
| way we think and responsibilities changes? wtf?!!
| camdenlock wrote:
| [flagged]
| doctor_eval wrote:
| Are you sure you linked to the right thing?
|
| https://news.ycombinator.com/item?id=34271510
|
| > Internet socialists / communists / transhumanists seem to
| infuse their content with a "chibi" vibe, filled with cuteness
| and hearts. Disagree with them politically, though, and watch
| out. The sunshine and roses suddenly become bloody slavering
| fangs.
| camdenlock wrote:
| I've never been more sure.
| meindnoch wrote:
| Flagged to death. Sigh...
|
| Kinda proves your point.
| operatingthetan wrote:
| Probably because it appears they are fishing for a political
| fight, and they are referencing their own vaguely related
| post from four days ago as if someone else wrote it ten years
| ago.
| ummonk wrote:
| How is a comment talking about whimsical content "only
| vaguely related"?
| operatingthetan wrote:
| The comment did not address any points in the article. It
| only mentions their view that a certain group uses this
| type of name. That's the "vague" part.
| [deleted]
| doctor_eval wrote:
| Right? Also, where are the "bloody slavering fangs"? It's
| just a blog post about whimsical naming. Some people will
| agree, some will disagree. Hardly a touchstone of "internet
| communists" or "transhumanists". And a bizarre perspective,
| considering who is behind recent events in the USA and
| Brazil.
| sph wrote:
| The saddest thing about our modern times is seeing how
| rejecting the status quo has been incorporated into politics.
| Once upon a time, one would reject politics and factionalism
| together with the cutesy corporate agenda you're ranting
| against.
|
| Now you get politicised posers like you blaming everything on
| "Internet socialists" and "communists".
|
| Party politics is not punk. Stop pretending it is.
| weitzj wrote:
| It get'a interesting when different companies decide to go down
| the Greek mythology pathway and the same service names pop up
| with different meanings in each company :)
|
| Also worth mentioning this as always humorous micrososervice
| video from Krazam many of you may know already:
|
| https://youtu.be/y8OnoxKotPQ
| djmips wrote:
| I worked at a place where they named all of the systems and tools
| with puerile gross words. They thought it was cute. I thought it
| was a chore and also not easy to keep straight.
| kmac_ wrote:
| Of course everybody knows what Galactus does!
| AceJohnny2 wrote:
| I've found this practice very useful when naming servers, which
| is an idea I picked up from the Debian project's infrastructure.
| A physical machine will have a cute hostname, and then the actual
| service it provides is a CNAME (DNS alias) to it.
|
| That way, the physical identity remains steady, but the
| responsibilities (CNAME) can move around (usually because of
| upgrade)
| ilyt wrote:
| I think it's excused if machine fulfills more than one function
| at once or needs some distinctor among many that fulfil similar
| function.
|
| If it is a LDAP server in DC1 it should just be "dc1-ldap" or
| "dc-ldap1" if you have few in redundancy (with actual service
| being either under "ldap" or "dc-ldap").
|
| But if it is a kitchen sink server running a bunch of services,
| eh, mjollnir will do, and if you do "ssh ldap" you will ssh to
| server that hosts LDAP service, regardless of what cute name it
| will have
| harryvederci wrote:
| I agree, it would be much better if the article url would be
| ntietz.com/puppy/cuddles-and-teddybears
| cosinetau wrote:
| Got a cute name for this: bikeshedding.
| jupp0r wrote:
| Just don't apply this to variable or function names please,
| thanks!
| kleene_op wrote:
| What? You don't want to sift through hundreds of pokemon and
| anime characters names totally unrelated to the variables and
| functions of the API you need to use for your job? I'll just
| write "not a team player" in your annual review.
| dottedmag wrote:
| I'm going through it right now, refactoring
| https://humungus.tedunangst.com/r/honk
|
| honk, zonk, honker, dunk, xonk... the list goes on. This is
| supposed to be ActivityPub server.
|
| Fun. Not.
| tgv wrote:
| > reverbolate ... grapevine ... bunchofgrapes
|
| I thought you were kidding, but you're not. Sad.
| jeroenhd wrote:
| It's like trying to learn frontend dev tools all over
| again. Too much gulping and grunting yarn for my tastes. I
| hear somehow bunnies are involved as well these days?
| zelphirkalt wrote:
| The purpose of naming things is to convey their meaning and
| character. By giving a non-descriptive name, one loses that
| potential. Please do not use cute names, unless there is really
| no good name to pick (like ad-hoc created docker container names,
| when --name is not specified). Give me information through means
| of naming things properly.
| jonstewart wrote:
| I work as a developer at a consulting company, and the
| consultants are constantly writing new scripts, Excel templates,
| and so on. Most are early career and get excited about having
| created something new, so they like using cute names. The
| practice has been to use a bird name.
|
| So my life consists of bewildering sentences about how raven is
| old and busted but blue throat will handle this situation,
| especially if used in concert with agelaius and peregrine, and
| run on a greyhawk.
|
| TFA is utterly wrong. A few things can perhaps stand the test of
| time and be worthy of a name, but use cute names sparingly. And,
| resist the urge to name something at all--it is far better to use
| umbrella terms inside an organization to avoid mass confusion by
| those that don't need to have day-to-day knowledge of your
| software.
| jrib wrote:
| We use bear names. It is fun and at this point (for me) the
| names are second nature.
|
| But the company merged recently with a couple of other
| companies and the confusion about polar bears versus grizzly
| bears versus panda bears is pretty funny at times (and counter-
| productive).
|
| I try to use both the code name and the descriptive name. So
| now I say something like: "grizzly marshmallow roaster" instead
| of just "grizzly".
| code_runner wrote:
| I worked for a company where everything was cute names with a
| particular outdoors theme.
|
| All of the conference room names had the same theme. Starting out
| it was impossible to navigate if we were even talking about a
| product or a conference room etc.
| discordianfish wrote:
| (Micro)service names should be descriptive and stick to doing
| what they are named after. If you need to change the scope, it's
| an change to the overall architecture and changing the name and
| good way to communicate that. If a employee reads the name they
| know what its suppose to do.
|
| Company and product names (including e.g open source projects)
| are different. You want to be able to change your scope depending
| on customer demand without having to rebrand.
| grahar64 wrote:
| I agree with this 100% and have seen this play out many times. At
| one company we named the service "Harry" after one of the
| employees kid's. Worked well, and I will fight for such names at
| any company I work at.
| atom_arranger wrote:
| Could not disagree more.
| beefield wrote:
| Well, I have worked in an environment where database server names
| were server software version concatenated with a shortish but
| high entropy random alphanumeric string. I'll take cute _or_
| descriptive any day over that.
| deltarholamda wrote:
| I've heard the "cattle not pets" argument for servers, but I
| hate that. Naming a server is like naming a boat. I've done it
| where everything is named after astronomers, or physicists, or
| even comic strip characters, but I also like it when a server
| is named, well, with a name.
|
| "Hey guys, Jeff is throwing errors again, need somebody to find
| out what Jeff's problem is."
| tremon wrote:
| It depends on scale. If you have 3 servers that you manage
| individually, you name them like pets. If you have 3,000
| servers that you manage through automation, you enumerate
| them like cattle.
| andy_ppp wrote:
| Yes, some places I've worked named servers with four numbers
| separated by full stops, it was crazy!
| quickthrower2 wrote:
| Even better if they are in the 0-255 range but different from
| the IP addresses they are using!
| moffkalast wrote:
| Satan: "I'd just like to say I'm a huge fan..."
| carlosrdrz wrote:
| Surely there is some middle ground? Why everything has to be
| black or white and everyone needs to give silver bullet rules?
|
| A service that stores something can be called "catalog" and it is
| descriptive, short and memorable. On the other hand, a service
| that does too many things can be called "zeus" or "cyclops" or
| whatever and that's okay too. It's difficult to have memorable
| and short names when things do too many things, or as mentioned
| in the post, they might change responsibilities.
|
| Also, when you have something descriptive composed of multiple
| words (like "data-streaming-analyzer") people will certainly
| start using acronyms (DSA) and then you're back to short names
| than don't mean anything.
|
| There's a world where everything is not called "pikachu",
| "cyclops", "potter" and "tortilla", nor "main-store-red-website",
| "download-analytics-store-and-processing", "sells-stream-
| processor". Use both. They are both useful!
| ryanjshaw wrote:
| I feel it's helpful to distinguish between "applications" and
| the "services" that make up those applications.
|
| - application name: not descriptive unless you are 100% sure
| scope will not change over time (e.g. a specific report
| mandated by a regulator); exception to the rule: I actually
| like using initialisms because they start off descriptive but
| then over time people use the initialisms exclusively and its
| almost like you invented a non-descriptive word without the
| initial confusion
|
| - service names: start with a monolith that is just the
| application name (or suffix "Core"), only split into other
| services once you have a good reason, and scope is clear, and
| then give it a descriptive name
| shove wrote:
| thats-bait.gif
| xorcist wrote:
| The right question to ask is how and when hostnames are
| serialized to disk and how you need to interact with them. The
| most common in my experience are for logging, metrics, backups
| and monitoring. So those interactions are important use cases to
| consider.
|
| In my opinion a good hostname, given an enterprise setting and in
| order of importance, should reflect 1) if the host is production,
| a staging area, or someone's toy, and 2) which group or team has
| responsibility or it. If relevant, also 3) what type of server or
| role it is.
|
| Should you find some sort of data dump or log that contains a
| hostname, it should be immediately obvious how sensitive it can
| be and with whom to speak. This basic requirement mostly rules
| out "cute-only" names.
| nzach wrote:
| The worst is when cute meets descriptive.
|
| I've worked at a place where we had dozens of microservices, all
| named after random mythology. And all names must had some
| relevance to the actual function of the service.
|
| The shopping cart service was named Freyja[0].
|
| The content management service was called Metis[1].
|
| Every single service had a 'cute but descriptive' name, and it
| was hell.
|
| If you didn't know that tale, the names don't mean anything. And
| if you do know you still have to guess what the the service does.
|
| [0] - https://en.wikipedia.org/wiki/Freyja
|
| [1] - https://en.wikipedia.org/wiki/Metis_(mythology)
| ilyt wrote:
| Metaphors don't qualify for cute but descriptive, there is
| nothing descriptive about it.
| bryanrasmussen wrote:
| I still don't get why Freyja would have something to do with a
| shopping cart?
| nzach wrote:
| If I remember correctly it was because she rode on a cart.
| jnsaff2 wrote:
| Dude(tte) is losing an argument so they turn to HN for more
| arguments by writing a trollish blog post.
|
| I find naming to be one of the most bikeshady of activities.
|
| Pick something and move along. The more you think/argue about
| them the worse the outcome.
|
| Channel your first instinct but be ready to change it once it
| turns out to be wrong.
| fein wrote:
| Does said argument have it's origins on here? I went to college
| with this guy (Assuming it's the same Nick Tietz) and thought
| it was satire, but I have no idea how people change over the
| years.
|
| That or we're on the bleeding edge of Poe's law.
|
| edit: It's far too early and my eyes skipped over the first
| sentence in the article.
| duffmancd wrote:
| Reminds me of [0].
|
| At work we tend to create backronyms for/from the cute names
| which is our way of having our cake and eating it too.
|
| [0] https://youtube.com/watch?v=y8OnoxKotPQ&si=EnSIkaIECMiOmarE
| thedorkknight wrote:
| So basically descriptive names _might_ eventually become non-
| descriptive, or loosely connected. "Cute" names are ALWAYS non-
| descriptive or loosely connected though. So at worst, a
| descriptive name eventually becomes as bad as a cutesy name.
|
| Given my experience being onboarded onto legacy code, and
| bringing others up to speed on my team's code, I'd much rather
| have names help coders understand the systems 9/10 times as
| opposed to 0/10 times
|
| I'm not sure I see the point
| toomanyrichies wrote:
| > descriptive names might eventually become non-descriptive
|
| It's worse than being non-descriptive- it's that they become
| _misleading_. "Cute" names don't tell you anything. Formerly
| descriptive names tell you _the wrong thing_.
|
| This, in turn, means developers _can no longer trust_ that a
| descriptive name is accurate. It plants a seed of doubt in a
| developer 's mind about _other_ names. It tells them that, here
| at WidgetCorp R &D, just because something is named
| DescriptiveThingThatDoesXYZ, doesn't mean it actually does XYZ.
|
| So now they have to verify what a given class or method does
| _every time_. Which means you have the same problem that cutesy
| names cause (the non-trivial effort of looking stuff up) _plus_
| the lack of trust that is now engendered in your engineering
| org.
|
| To be clear, I _think_ I still fall more towards the "use
| descriptive names" camp. As another commenter has said, by
| making it easier to add responsibilities to a certain class or
| service, the "use cute names" camp promotes the creation of God
| objects that take on too many responsibilities. But _man_ I
| hate it when a class 's name is actively misleading.
| surement wrote:
| > It's worse than being non-descriptive- it's that they
| become misleading.
|
| if you find that something has drifted to the point of being
| misleading, then rename it
|
| it's software not hardware
|
| or comment on code reviews that change the functionality to
| the point where this is a problem
| toomanyrichies wrote:
| > if you find that something has drifted to the point of
| being misleading, then rename it
|
| Sure, this is the proper course of action _when that is an
| option_ , but...
|
| > it's software not hardware
|
| ...if the "software" is a 3rd-party library that external
| stakeholders are consuming, then it may as well _be_
| hardware, because those class and method names represent an
| API contract that the library 's users expect to remain
| consistent. Which means changing them involves a non-
| trivial change management and versioning process. Even when
| the code is internally-facing only, in a large enough
| codebase it's often the case that multiple teams (and their
| respective codebases) depend on those names, increasing the
| complexity of a rename.
|
| > or comment on code reviews that change the functionality
| to the point where this is a problem
|
| Again, this is the right move _if it 's available to you_.
| We don't always have that luxury if the names have already
| gone off-course by the time we first encounter them. Which
| is often the case an an older codebase that has been
| written and re-written by many employees who have come and
| gone over time.
|
| Again, I continue to believe that I'm a member of the "do
| NOT use cute names" camp. But I'm seeing a lot of
| cavalierness in these comments about "just rename it,
| what's the big deal?" and experience tells me that it's not
| always that easy.
| salawat wrote:
| >It's worse than being non-descriptive- it's that they become
| misleading. "Cute" names don't tell you anything. Formerly
| descriptive names tell you the wrong thing.
|
| My God... You don't mean to tell me you actually _object to
| having to read code and figuring out what it does in the
| grand scheme of things?_
|
| I swear, everyone wants to be a writer, but no one wants to
| read and understand.
| toomanyrichies wrote:
| Not only is your comment needlessly snarky, but it also
| mis-characterizes what I said. Show me where in my comment
| I said that I "object to reading code and figuring out what
| it does in the grand scheme of things".
|
| What I "object to" is not being able to trust that a class
| or method does what it says on the tin. I don't think
| that's unreasonable. I'm fine with reading code in order to
| understand _how_ something works. I don 't want to have to
| read code in order to _verify_ that it does what it
| promises. See the difference?
| grahar64 wrote:
| You shouldn't have to read code to understand architecture.
| But I have had so many conversations like "this is the
| Auth-service, it also loadbalances and stores a bunch of
| state, oh and doesn't do Auth anymore". Then the name
| becomes actively harmful to understanding the system.
| thedorkknight wrote:
| I suppose. But even though I've definitely dealt with poorly-
| named microservices in my career, I can't really say as I've
| come across many that stuck out to me as being especially
| misleading, and not to the point where it was really an issue
| PragmaticPulp wrote:
| Cute names are fun when for a few special things here and there.
|
| Cute names are a nightmare when a company has accumulated
| hundreds of quirkily named things that you have to memorize just
| to navigate through the basics of trying to get your job done.
|
| New hires suffer the most. It's an extra layer of company-
| specific jargon that you have to learn to even begin to
| understand what your peers are talking about.
| throwaway14356 wrote:
| how else will you know they are new hires? They will have to
| spend time petting the fuzzBear just like everyone else!
| eps wrote:
| Even HN frontpage sometimes be "How I use Kawai Wasabi on
| Yakotori under Sashimi" and there'd be 100 comments, all of
| them serious. Makes one feel excluded.
| alexvoda wrote:
| Kawai Wasabi is incompatible with Yakotori. It is a known
| choice by the lead developer.
|
| When using Yakotori you should use Tare instead.
| moffkalast wrote:
| Yeah but Tare doesn't scale as well as Marmot, plus it has
| Tenimoshi support.
| rapnie wrote:
| I remember Yashi worked on this support, it is great.
| progx wrote:
| I thought he was replaced by Mushi Mushi?
| reportgunner wrote:
| Use the Babushka fork, it's still being maintained.
| mindcrime wrote:
| Presumably by somebody in Mornington Crescent?
| lo_zamoyski wrote:
| Would you please pass the jelly?
| debugnik wrote:
| The _JSON Encrypted Lightweight Long Yakisoba_ message?
| moehm wrote:
| Is Tare even maintained? I tried to build it with Mochi,
| but it gives weird error messages.
| seniortaco wrote:
| Why would anyone still build it manually? Tokidoki
| automates all of that, and all you have to do configure
| your .toki bundles after you've installed the right
| SpaghettiWare layer for your architecture and connect it
| with either Tutti or Frutti. Easy peasy lemon squeezy! Oh
| that reminds me you do need Squeezy running in the
| background.
| liotier wrote:
| Uh ? Aren't your .toki bundles autogenerated from picks
| in the CherryOrchard directory ? Don't touch them - let
| the NoodleBlossom pipeline trellis abstract that for you
| !
| seniortaco wrote:
| Oh goodness, well I was just on a two week vacation and
| it looks like NoodleBlossom was created last week, I feel
| like some kind of cave person over here! Trellis
| pipelines are slick!
| [deleted]
| DaedPsyker wrote:
| Tech naming has become a pet peeve of mine. Too many common
| nouns are being used.
|
| Something like coffeescript is at least distinct but then you
| get a hundred things that will be called something like apple
| juice, based on some in-joke connected to a stack that will
| be called orchard.
| Damogran6 wrote:
| Verbnouns - ActiveCrab, StormTorch, Plinth, Bonobo,
| ElasticStack, FrodoBlight
|
| And at a conference, you'll have two animated people
| arguing over the use of...well...I didn't quite get it, it
| was loud, but it was the solution to all things and I'll
| never find out what it was, because what I _thought_ I
| heard was Spogdog, but Google's got NOTHING.
|
| (If only I knew it was SpOgDog)
| jnsaff2 wrote:
| One of the cute names horrowshow for me is Chef. Everything is
| based on some supposedly cooking analogue that just does not
| fit with (at least my) mental model of IaC.
| amiga386 wrote:
| Absolutely this! In case anyone isn't aware of the insane
| thematic naming in Chef:
|
| _Chef_ = a configuration management tool
|
| _Recipe_ = an individual Ruby script that makes sure
| something is installed and configured correctly (e.g. a mysql
| recipe)
|
| _Cookbook_ = a bundle of recipe(s) and basic metadata (what
| do these recipes do, who wrote them, etc.)
|
| _Supermarket_ = a community site with common cookbooks, what
| others would call a "hub", "central repository",
| "marketplace" or "store"
|
| _knife_ = a command line tool for managing your chef
| installation
|
| _Test Kitchen_ = a test suite runner
|
| _Cookstyle_ = a code linter
|
| However, now that Chef has gone full Enterprise (never go
| full Enterprise), the names are now all enterprisey-sounding:
| everything is "Chef XYZ", e.g. "Buzzword you know + Buzzword
| you don't", harnesses the CxO's FOMO. Chef Habitat = write
| declarative rules for applying cookbooks to machines. Chef
| InSpec = auditing/compliance. Chef Workstation = what you
| would have normally installed anyway, the development kit and
| runtime tools, but now it's EnTeRpRiSe, ...
| xorcist wrote:
| Puppet went full enterprise too and now there's a dizzying
| amount of "products" catering to your needs.
|
| It's written on the wall for Ansible, Red Hat/IBM is busy
| churning out the product space already.
|
| It's weird that there's so much money in enterprise IT. If
| anything, they should know the value of standards and
| reference implementations.
|
| Almost 25 years ago, SSH went full enterprise and promptly
| died. Somehow the need for a simple remote shell protocol
| didn't, though, and now OpenSSH is instead perhaps the most
| valuable tool we have.
| ghostpepper wrote:
| I had no idea there was ever a company called SSH but
| apparently they still exist . Seems they were way ahead
| of the curve on what became known as "open core"
| Macha wrote:
| Homebrew is another project that overdoes it IMO
| mostertoaster wrote:
| This is because cook books while useful, aren't entertaining
| stories. Now if they named it after a good character from a
| story everyone knows, say the hunter from the big bad wolf,
| and it's purpose was to chop up evil wolves taking advantage
| of grandmas and little girls with baked goods, then everyone
| knows that character, and as long as the purpose of the
| service is to defeat impostors trying to do harm then it is
| fitting.
|
| And if the junior doesn't know the story of little red riding
| hood, well then it is your lucky day and you are one of the 1
| in 10000 who gets to tell them the story.
| ihatepython wrote:
| My default is to name the project something related to
| Darmok and Jalad at Tanagra.
|
| Then when things go off the rails, I can say 'Shaka, when
| the walls fell'
| cbm-vic-20 wrote:
| And when the other person in the conversation looks
| perplexed or lost, just repeat it again, slowly, and add
| emotion to some of the syllables. They'll get it
| eventually.
| voytec wrote:
| Names of my mail systems :)
| Izkata wrote:
| > Now if they named it after a good character from a story
| everyone knows
|
| Darmok and Jalad at Tanagra.
| mostertoaster wrote:
| ;) https://xkcd.com/1053/
| bbarnett wrote:
| How strange! Why wouldn't he just tell her to google it,
| and go back to looking at his phone?
| dclowd9901 wrote:
| As an Amazon developer, I feel this. No wonder it's so hard to
| get shit done.
| atoav wrote:
| I say, go for both. Go all Boaty McBoatface on that thing.
| Boaty McBoatface is silly, but it is unarguably a memorable
| name for a boat.
|
| There are other, less silly, but equally memorable (and maybe
| even cute) descriptives out there.
|
| On a different note: if you are presented with an either/or
| choice, your first instinct should _always_ be to ask if they
| are actually opposites or if you can also have both if clever.
| nsonha wrote:
| > memorable name
|
| is it ever a problem in software engineering, that you can't
| remember what that component's name is?
|
| I find it more of the problem when people make a good library
| that solves a problem with a predictable name, but then they
| give their library some other cute name, and maybe they don't
| do SEO well on package repositories (why would they, software
| engineers). So, when I look npm up for that problem, their
| lib would not even come up.
| Conan_Kudo wrote:
| > _is it ever a problem in software engineering, that you
| can 't remember what that component's name is?_
|
| Yes. When the names are descriptive or bland, it's almost
| impossible to remember what it _is_.
| nsonha wrote:
| Question wasn't if people forget names in software, it's
| whether forgetting names is a problem. Like I forget
| names of things in the codebase MULTIPLE times per day,
| but I don't, and am not aware of anyone naming variables,
| functions etc in order for them to be memorable (as
| opposed to descriptive). I neither need nor want to
| memorize those names, I have other things more
| interesting to fill up my memory with.
| atoav wrote:
| > I find it more of the problem when people make a good
| library that solves a problem with a predictable name, but
| then they give their library some other cute name
|
| This is why I said Boaty McBoatface. You look for Boats? It
| has "boat" literally two times in it's name.
| nicbou wrote:
| https://youtube.com/watch?v=y8OnoxKotPQ&t=40
|
| This is how it ends up sounding like.
| ThePhysicist wrote:
| Came here to post this as well. It's exaggerated but only
| slightly.
| mrweasel wrote:
| The whole Cloud Native Landscape is full of BS like this: Kong,
| Skipper, Harbor, Calico, Helm, Linkerd, Flannel, you add the
| next 50 or so project that I forgotten. It makes the entire
| thing really complex to navigate, and impossible to talk to
| others about, because they may have plugged in some network you
| don't know, but you don't know that it's a network, because the
| name provides zero clues. Or there might be clues, if English
| is your native language, otherwise too bad.
|
| It's this needless layer of jargon that doesn't help with the
| understand of the solution.
|
| Sure, if there's a reasonable chance that your project becomes
| absolutely massive, then a unique name is a great idea. For
| internal project, don't be cute, just call the thing by its
| function. Your warehouse management system should just be "the
| WMS", not FluffoTron. Should it happen to take on new
| functionality, then either split that out in a separate
| project, or just rename the whole thing.
| avanai wrote:
| I'm not a huge fan of cutesey names but a lot of those names
| are variations on or homages to Kubernetes (Greek for
| "Helmsman"): e.g Skipper, Harbor, and Helm from your list.
| MichaelDickens wrote:
| At my last job, I kept a list in my notes of about 20 service
| names with explanations of what they did because they all had
| cutesy names that gave no indication of their purpose and I
| could never remember which one was which.
| feoren wrote:
| > Cute names are a nightmare when a company has accumulated
| hundreds of quirkily named things that you have to memorize
|
| Now imagine trying to navigate hundreds of things that are
| descriptively named _wrong_. The argument isn 't between (A)
| cutesy names, and (B) accurate descriptive names. B is
| obviously better. But that's a fantasy world that doesn't
| exist. The argument is between A and (C) descriptive names that
| rot over time (quickly or slowly), which is actual reality.
| IshKebab wrote:
| This is the sort of nonsense argument people use to justify
| not writing comments. "But the comment might get outdated!!"
|
| Yes it might. But it probably won't, or it will be obviously
| outdated, or outdated in trivial ways or you can use Git
| blame to check how the code was when it was written. All of
| which is better than no comments 99% of the time.
|
| The number of times I've read a comment and eventually
| thought "oh damn that was misleading, I wish that comment
| wasn't there" is like... 10 in my whole life.
|
| The number of times I've thought "why does the foo-service
| also do bar? I wish they'd named it completely randomly
| instead" is precisely zero.
| seti0Cha wrote:
| No, the alternative is having 100s of things that are
| basically right, with a few that are misleading. I'll take
| that any day over all cute names, because I only have to
| remember the exceptions. Not theoretical, I've been in that
| situation. Also, purpose drift is technical debt. Using
| meaningless names is just a way of hiding that debt. A
| service that doesn't match it's name has evolved into a bad
| place and needs to be refactored. You want to be able to see
| that.
| devnullbrain wrote:
| This would actually make the situation in TFA worse. The new
| hires would assume that foober foos when actually it's being
| used to bar. Either way there's a need to memorise - without
| cute names you gain the additional problem of close but
| dangerously wrong assumptions.
|
| Reading documentation is not a bad expectation of a developer.
| doctor_eval wrote:
| Yeah but surely there is a directory somewhere that explains
| this?
|
| I mean - the problem is not the number of names but the number
| of services. A new hire still isn't going to be able to work
| out what a service does just based on the name, regardless of
| how whimsical or apt it is.
|
| "policy-engine" might seem to be a good name for a service, but
| it's only one level below "kevin" in terms of opaqueness,
| especially when there are probably several policy related
| services.
| ummonk wrote:
| "policy-engine" is an example of a name that is neither cute
| nor descriptive
| godelski wrote:
| It's an example of descriptive but how being terse,
| descriptive, and unique is quite difficult.
| doctor_eval wrote:
| But that's my point. You start writing a new policy engine,
| and you think the name is _obviously_ descriptive. But in
| 12 months time, it 's not so obvious any more, and also you
| probably have 3 different policy engines for different use
| cases.
| ummonk wrote:
| It should be pretty apparent even from the start that
| that isn't a descriptive name.
| doctor_eval wrote:
| Be kind. Don't be snarky. Converse curiously; don't
| cross-examine. Edit out swipes.
| bryanrasmussen wrote:
| Ok but the image-optimization-engine that Carl wrote
| still seems descriptive to me those same 12 months later.
|
| So I think policy-engine might have seemed descriptive
| but it just wasn't whereas image-optimization-engine was
| descriptive.
| Drakim wrote:
| At least until it also starts converting gifs to webm,
| and soon other formats like mp4, and since it's being
| used for video it needs subtitle support in various
| languages.
| marcosdumay wrote:
| You mean a generic policy-engine? One that reads code-as-
| configuration from a database, executes arbitrary I/O, and
| gives back a result?
|
| Very few times somebody starts something like this. And
| yes, they do have cute names, because they don't have any
| short identification.
| kzrdude wrote:
| Directories somewhere that pedagoically explain all the
| codenames, nah that doesn't necessarily exist in the company
| until it grows larger. It might just be a quagmire for new
| hires in a growing company.
| xorcist wrote:
| A directory does wonders. Make it hierarchical too. That way
| different zones can have different values.
|
| It can point "policy-engine" to which host runs it. Or, even
| better, make it resolve the IP address directly!
| drstewart wrote:
| >Yeah but surely there is a directory somewhere that explains
| this?
|
| No, there's 5 different directories in 3 different formats
| compiled across the last 8 years representing the state of
| 80% of terms at the time it was last updated, half of which
| disagree with another version.
| doctor_eval wrote:
| I gotta say, I think that's actually just bad technical
| management, so I suppose it's probably common. Although I
| will admit Conway's law here.
|
| Nevertheless, the same phenomenon that leads to multiple
| directories will also mean that supposedly "descriptive"
| names, will not be.
| ls15 wrote:
| I can confirm this
| ShredKazoo wrote:
| Compromise: Come up with a cute name that vaguely suggests what
| the project does. E.g. instead of "broadcast-service", name it
| "Cronkite" or "NBC".
| fckgnad wrote:
| Nooo acronyms are horrible. When you have hundreds of
| services that are acronyms it becomes a nightmare.
| fiddlerwoaroof wrote:
| I have the opposite problem as a recent new hire: when "cute"
| project names show up in a conversation, it signals something
| company-specific I need to learn about. When descriptive
| project names are used (especially if the projects are using
| really generic one or two word names like "routing-service"),
| it is harder to realize that people are talking about an
| implementation of a concept rather than a well-known concept.
| mattigames wrote:
| This is basically by fast the best argument to use cute names
| over some main components, and by "main" I mean when there
| are few of them, less than a dozen or so.
|
| An old name made of well-known technical words can easily
| suggest a level of complexity much smaller than what it has
| evolved into and therefore developers -specially new devs-
| should look it up instead of assuming what it does based on
| potentially misleading namings.
| hooverd wrote:
| What's not to understand about the account-provider-router-
| service? It's key to the business-data-sync service. We're
| working on a new account-provider-aggregator to replace it
| though.
| leeches wrote:
| Solved with company name or product name prefixes, like
| "discord-routing-service"
| ghostpepper wrote:
| except nobody at discord would ever call it "discord
| routing service" in a conversation with other discord
| employees
| sirsinsalot wrote:
| Handily, DRS and other D-prefix acronyms are easy to
| spot, hear, use and map to useful names.
| JackFr wrote:
| You can have the worst of both worlds. I've worked at three(!)
| seperate companies which have had projects called 'Hydra' (and
| the number of people who were ignorant of what the Hydra was,
| and why it might not have been a great name for a software
| project never ceased to amaze me.)
|
| I like clever, cute names. That is names like Hydra, Spirit,
| and others which are unrelated to the function, but which are
| anodyne and generic and not terribly uncommon end up being the
| worst.
|
| (I have a soft spot for clever names, my favorite is still
| Leiningen the clojure build system:
| https://en.wikipedia.org/wiki/Leiningen_Versus_the_Ants)
| nivenkos wrote:
| It feels like every company has an Apollo, Hydra or Hermes...
| mook wrote:
| I worked at a startup with a bird theme for a bit under 4
| years. There were three separate things named Nightingale in
| that time. By the time I left, it was kind of a joke to
| suggest that as the name for random things.
| mypalmike wrote:
| Nightingale was probably also the name of a meeting room.
|
| I managed to avoid creating any new tools or services with
| bird names during my time there, though it was tempting to
| do so.
| adrianmsmith wrote:
| > New hires suffer the most. It's an extra layer of company-
| specific jargon that you have to learn to even begin to
| understand what your peers are talking about.
|
| I wonder if that's the point, and why certain people use weird
| names for things. They're senior engineers, they get a nice
| salary, it's rational (albeit not in the interest of their
| employer) to prevent their job getting taken over by a junior
| developer. So they have to set up roadblocks, moats, barriers
| to entry etc., and weird service names are one such barrier.
|
| In general team members are going to look after their own
| interests (e.g. set up roadblocks), but if this sort of stuff
| goes on it shows bad engineering leadership within the company,
| as it's the leadership's responsibility to stamp down on this
| sort of behaviour.
| ilyt wrote:
| You need to do it anyway if your names are _too_ descriptive*
|
| "video-encoder is not working"
|
| "oh, you mean ffmpeg"
|
| "no, our microservice is called video encoder"
|
| Also they are not neccesarily one or the other, you can name
| something that hints at its function but it is not straight
| dictionary description of it.
| surement wrote:
| > "no, our microservice is called video encoder"
|
| using cute names shouldn't be an alternative to learning to
| name things properly
| andylynch wrote:
| Also becomes awkward and distracting having to explain to other
| peoples' lawyers (or government officials!) what those cute
| names represent when things go wrong.
| micro_charm wrote:
| Feel like this article was intentionally written to validate
| Cunningham law and to promote bikeshedding. It's an almost
| perfect trap for that
| feoren wrote:
| Early chemists gave cutesy names to chemicals, like "vitriol",
| "salt", and "cholesterol". Today we know the _proper_ descriptive
| names for these substances, of course.
|
| Vitriol's _correct_ name is "sulfuric acid".
|
| Salt's _correct_ name is "sodium chloride"
|
| Cholesterol's _correct_ name is "(1R,3aS,3bS,7S,9aR,9bS,11aR)-9a
| ,11a-Dimethyl-1-[(2R)-6-methylheptan-2-yl]-2,3,3a,3b,4,6,7,8,9,9a
| ,9b,10,11,11a-tetradecahydro-1H-cyclopenta[a]phenanthren-7-ol".
|
| That's not a name! It's a serialization of a molecular structure!
|
| See, the problem is that what's "descriptive" is opinionated, and
| a hot topic for bikeshedding. It's like the argument between
| natural and artificial primary keys. If you go with natural
| primary keys, expect managers to bikeshed exactly what's in there
| and how it should be encoded. They'll change all the time. Your
| "name" turns into an encoding of the object itself. If you call
| your computer "OaklandDev19InTheBasement" then what happens if
| you move? What happens if you get more than 100 dev computers in
| the Oakland basement? How many arguments are you going to have
| about whether it's the proper place to put some service that may
| not be "devvy" enough?
|
| Some people are hitting this, but most of these can be broken
| into different functions:
|
| Identity: always meaningless, always.
|
| Finding a service: if this is hard, you need a directory. You
| need this anyway, even with descriptive names. If you need a
| directory, can you automate it?
| kerkeslager wrote:
| There are so many straw man arguments in this post it's hard to
| play them apart.
|
| > Early chemists gave cutesy names to chemicals, like
| "vitriol", "salt", and "cholesterol". Today we know the proper
| descriptive names for these substances, of course.
|
| That's not what happened, and nobody is saying that the
| chemical serialization is the "correct" name. The reality is
| that originally we didn't know the internal structure of these
| chemicals or understand how they functioned: referring to
| something as an acid didn't matter because we didn't understand
| how acids worked. The naming grew as our understanding of the
| function grew.
|
| But, critically, the old names are still useful in some
| contexts, because the chemicals serve different functions in
| different contexts. Nutritionists don't necessarily need to
| know that Vitamin C is an acid, and they certainly don't need
| to know the exact chemical structure of cholesterol. In fact,
| it's telling that your chemical structure actually is just one
| form of cholesterol, because cholesterol is a group of
| chemicals, not one chemical.
|
| More fundamentally, naming the structures of chemicals is
| different from naming services, because chemicals don't change.
| Sulfuric acid will always be H2SO4, and it will always react
| the same given the same conditions. That's not true of
| services.
|
| > See, the problem is that what's "descriptive" is opinionated,
| and a hot topic for bikeshedding.
|
| Sure... but the answer is just "don't do that". If you spend 30
| hours a week arguing over whether something is a "adapter" or a
| "converter" that's a waste of time, because those terms are
| both pretty similar. No one is saying that's a good idea. That
| doesn't mean that we should just throw up our hands and name
| the object "SamuelLJackson", it means we should give things the
| most descriptive name we can come up with in, say, 30 seconds.
| Which, for something that changes objects from one format to
| another, isn't SamuelLJackson.
|
| Part of the problem I'm seeing here is that people seem to be
| concerned that name changes are a waste of time. That's true to
| some extent, but having to figure out what a poorly-named
| entity does is a much larger waste of time. And if it isn't, I
| have to ask, why is changing names taking so long? Perhaps it's
| a lack of tests? Poor editor tooling? Whatever it is, fix
| whatever is making your names hard to change, don't give up on
| descriptive names.
| feoren wrote:
| > The naming grew as our understanding of the function grew.
|
| Yes! That's exactly it! You have accidentally made my point
| exactly. The name grows as the understanding of the function
| grows. And your understanding of what a given service or
| application should be doing is always growing and changing
| over time. So if your name is an encoding of the function, it
| will constantly change and grow, until it's as ugly and
| useless as Cholesterol's "true" name.
|
| > Nutritionists don't necessarily need to know that Vitamin C
| is an acid, and they certainly don't need to know the exact
| chemical structure of cholesterol.
|
| Yes! That's exactly it! Your CRM program doesn't need to know
| that your spell-checking service is also a translation
| service, and your international logistic program doesn't need
| to know that your translation service is also a spell-
| checking service. So the name "TextCheckerTranslator" is
| partially irrelevant to both. And what happens when you add a
| third function to it? It now can also do OCR. So now your CRM
| program, which only cares about the "checker" part, needs to
| be re-compiled or have its config changed because it now
| needs to call the "TextCheckerTranslatorOCR" service instead.
| Every downstream service has to be changed because of changes
| that have _nothing_ to do with them! Just call it
| "Wordsmith".
|
| > More fundamentally, naming the structures of chemicals is
| different from naming services, because chemicals don't
| change. Sulfuric acid will always be H2SO4, and it will
| always react the same given the same conditions. That's not
| true of services.
|
| _Our understanding_ of chemicals changes, just like our
| understanding of which services should do what (and what that
| means) changes. But either way, if services are _more_ likely
| to change, then all the more reason to use artificial names
| for them (rather than trying to encode all their purposes).
|
| > Sure... but the answer is just "don't do that". If you
| spend 30 hours a week arguing over whether something is a
| "adapter" or a "converter" that's a waste of time, because
| those terms are both pretty similar. No one is saying that's
| a good idea. That doesn't mean that we should just throw up
| our hands and name the object "SamuelLJackson", it means we
| should give things the most descriptive name we can come up
| with in, say, 30 seconds. Which, for something that changes
| objects from one format to another, isn't SamuelLJackson.
|
| Absolutely spot on. I spent about 30 seconds coming up with
| "Wordsmith". It does something with words. I agree the word
| should not be _completely_ divorced from its use.
| SamuelLJackson would be a good name for a service which takes
| boring text and liberally inserts creative swear words into
| it.
|
| > Part of the problem I'm seeing here is that people seem to
| be concerned that name changes are a waste of time.
|
| We all treat "hiding details" important in code. If every
| part of my code depends on every other part of my code, then
| one change will mean 100 changes. The answer isn't "well,
| just make sure those 100 changes are super fast, and ignore
| the constant thrashing in your git history". The answer is
| standard programming practice of sharing only the details
| that are relevant to others.
| kerkeslager wrote:
| > > The naming grew as our understanding of the function
| grew.
|
| > That's exactly it! You have accidentally made my point
| exactly.
|
| No, you just ignored the point I made later about it being
| contextual.
|
| > > Nutritionists don't necessarily need to know that
| Vitamin C is an acid, and they certainly don't need to know
| the exact chemical structure of cholesterol.
|
| > Yes! That's exactly it! Your CRM program doesn't need to
| know that your spell-checking service is also a translation
| service, and your international logistic program doesn't
| need to know that your translation service is also a spell-
| checking service.
|
| 1. ...but your CRM service does need to know that your
| spell-checking service is a spell-checking service, and
| your international logistic program does need to know that
| your translation service is a translation service.
|
| 2. Your spell checking service shouldn't also be a
| translation service, and your translation service shouldn't
| also be a spell checking service. If you violate single
| responsibility principle, then "Play stupid games, win
| stupid prizes" applies. Naming is the least of your
| problems in this situation.
|
| > Absolutely spot on. I spent about 30 seconds coming up
| with "Wordsmith". It does something with words.
|
| Well, maybe until you're better at it, spend more time.
|
| > I agree the word should not be completely divorced from
| its use.
|
| Then you disagree with the OP.
|
| > We all treat "hiding details" important in code. If every
| part of my code depends on every other part of my code,
| then one change will mean 100 changes.
|
| Again, play stupid games, win stupid prizes. If every part
| of your code depends on every other part of your code, _don
| 't do that_.
|
| > The answer isn't "well, just make sure those 100 changes
| are super fast, and ignore the constant thrashing in your
| git history". The answer is standard programming practice
| of sharing only the details that are relevant to others.
|
| Surely _what the thing you 're calling does_ is relevant to
| you?
| shkkmo wrote:
| Of the three you mention, only "cholesterol" was actually named
| by an early chemist [0]. "Oil of vitriol" was first mentioned
| by an alchemist almost 1000 years ago but the term "vitriol"
| already existed to refer to some metal sulfates. "Salt" is much
| much older.
|
| [0] https://en.wikipedia.org/wiki/Michel_Eug%C3%A8ne_Chevreul
| feoren wrote:
| > first mentioned by an alchemist
|
| I was really hoping we'd all be mature enough to not have
| this petty argument over when people _studying the properties
| of chemicals_ stopped being called "alchemists" and started
| being called "chemists". What year was that, exactly?
| Exactly. I need an exact year, so I don't make this "mistake"
| again, please. Because otherwise, I think "early chemists" is
| a perfectly accurate description of early humans studying the
| properties of chemicals.
| whatshisface wrote:
| The transition was gradual but did happen, and on one side
| you had a lot of pseudo-religious beliefs and on the other
| you had experimentation and the scientific method.
| feoren wrote:
| And this distinction is important enough to you that
| you'd like everyone who refers to pre-20th century humans
| who _studied the properties of chemicals_ as "early
| chemists/alchemists", and if they don't, you're going to
| correct them? Even if it's irrelevant to their main
| point? That's the discourse we want on here?
|
| _Everyone_ had pseudo-religious beliefs back then! Can
| we not talk about "early astronomers" who were studying
| the movements of stars and planets, if they also believed
| in other weird shit? Who cares if they were studying the
| stars in order to sacrifice goats at better times?
| serverholic wrote:
| Even if it's imperfect, a descriptive name is quite nice
| because at least it gives you a hint as to what the service
| does.
|
| I find the comparison to cholesterol to be a bit ridiculous.
| Your argument seems like a case of "well technically this
| strategy is imperfect so we shouldn't even try."
| dudeinjapan wrote:
| So... why did the author give this blog post a descriptive title?
| Wouldn't a better title be "Fluffy Bunny"?
| rikkuri wrote:
| Descriptive name guards from feature creeping because every one
| understands the scope of service. If it is always tempting to add
| new features to the existing services, creation of new services
| should be done to be easier.
| paxys wrote:
| You really think a name is going to hold anyone back from this?
| resonious wrote:
| Right, the article itself actually uses this as a compelling
| reason _for_ cute names. If I release "X service", then it
| inevitably becomes "X and Y service" and the old name is now
| misleading.
| drewcoo wrote:
| I think code reviews might.
| stiiv wrote:
| > The problem comes in when there's a mismatch between
| responsibilities and names. Names are a way of expressing
| identity, while responsibilities are ephemeral: Your friend Sam
| is still Sam, even if Sam gets new responsibilities and sheds old
| ones.
|
| This analogy falls short. Services aren't like people -- their
| names aren't bound to their origination, but they can be bound to
| their function. That's a choice for a developer to make.
|
| But how common are are actual mismatches between service
| responsibilities and names, really?
|
| What kinds of systems or features or teams do name/function
| mismatches commonly track?
|
| Speaking strictly for myself: I've worked on SOAs and
| microservices (mostly for .NET) since 2005 for half a dozen
| companies on both new and existing systems, and I can't recall
| _any_ such mismatches.
| mostertoaster wrote:
| Wrong answer.
|
| Names should be cute AND descriptive.
|
| His point is good though. Descriptive names add overhead that
| might need to be changed.
|
| Giving something a cute name but describes its general purpose,
| means you have a lot of leeway, but if you get to the point where
| even the general name doesn't work and you want to change it,
| then you actually have a new product and creation is better than
| evolution when it comes to software.
|
| Joey, the small service that hops from one place to the next in
| what seems like ~~ab~~an endless loop, is like a baby kangaroo,
| and it can even grow into a real kangaroo and do whatever they
| do, but it isn't gonna become a fire breathing dragon, and if
| Joey is trying to be forced into being a dragon instead of a
| kangaroo, well maybe it's time to start from the beginning and
| decide which programming language to use ~~snd~~and go from
| there.
|
| Think of it, instead of writing software, we just write fantasy
| stories, and the software that tells the story is our product.
|
| I don't know about you but I could probably come up with some
| cool stories of Joey the baby kangaroo.
|
| I'm going to start a company and name all the services and APIs
| supporting the software after the best characters from mythology,
| and just start making good characters and then figure out where
| they go in the story.
|
| The story is already written, but the characters have to be
| fleshed out.
| trynewideas wrote:
| I worked in a non-engineering role at a place that used cutesy
| names for almost everything: meeting rooms, engineering teams,
| internal tools and libraries, events. Nothing was descriptive,
| and even just fundamental roles and responsibilities were
| institutional knowledge. (They were "documented", but nobody was
| responsible for updating the docs when people left/moved/were
| added.)
|
| So when a customer complaint about messaging came across my desk,
| I'd first have to figure out which team to go to: Ice Cream,
| Teddy Bear, Jetski, or Pineapple.
|
| What parts of the product does Ice Cream work on? Do they work on
| the messaging protocol? Or was it the app server? Oh, didn't you
| hear, Jetski took on the app server last month and this week
| they're spinning off the messaging protocol into a new team,
| Applejack. Now Ice Cream's only responsible for user
| authentication.
|
| Okay! Cool, so who's in Applejack? The Software Mage for the
| BrokenLighthouse library, which implements the messaging
| protocol? No, actually it's the Product Master for
| BrokenLighthouse's replacement, WorkingSignal. BrokenLighthouse
| maintenance is still with Ice Cream.
|
| Okay! So is the Software Mage for BrokenLighthouse still on Ice
| Cream, like the directory (sorry, the Cast of Characters) says?
| No, they transferred to Jetski with the app server, sorry, I mean
| AppleBucket team.
|
| Okay! I'll just join #jetski... wait, it doesn't exist anymore.
| Oh, right! Now that they have AppleBucket they renamed to
| Appleski.
|
| Okay! I'll just join #appleski. (Damn it, Slack, don't
| autocomplete it to #applejack or #applebucket-feedback.) "Hey,
| I've got a support ticket for a messaging protocol issue, can
| someone help?"
|
| > Sure, we're meeting in Batman on that right now! Come join us!
|
| Okay! Where's Batman? The office has two floors, Cartoons and
| Comics, and each is divided into four themed quadrants, and each
| room is named after someone in one of those quadrants. So
| Cartoons is split into Adult Swim, Looney Tunes, Simpsons, and
| Disney, and Comics is split into DC, Marvel, Dark Horse, and
| Newspaper.
|
| Counterintuitively, I loved watching Batman:TAS as a kid before I
| knew it was a comic book, so I always wind up wandering around WB
| looking for Batman. "Where's Batman?" Oh, Batman's in DC,
| upstairs.
|
| Okay! I enter Batman and find Appleski talking about
| BrokenLighthouse.
|
| "Hey! Is this where I can ask a customer question about the
| messaging protocol?"
|
| Blank stares.
|
| "Sorry. Is this where I can ask about this BrokenLighthouse error
| message that just says 'AppleBucket is refusing LightBeams from
| BrokenLighthouse due to a misconfigured PineappleSkin'?"
|
| > Oh sure! That's just the message protocol saying there's a
| syntax error in the config YAML. The v2 protocol will switch to
| JSON and provide more detailed feedback.
| raydiatian wrote:
| Yeah this seems like a _terrible_ argument. Here is what
| onboarding looks like, if we all followed this:
|
| "Okay so, the part of the app you're working on is weeble-wobble
| which handles transactions. Weeble-wobble interfaces with poopy-
| leg to create financial reports, and with screaming-kidney to do
| fraud analysis."
|
| Maybe this is fine for devops? I mean, if pets, not cattle is the
| regime within the org
| brianpan wrote:
| Don't forget about Galactus, the all-knowing user service
| provider aggregator.
|
| https://www.youtube.com/watch?v=y8OnoxKotPQ
| raydiatian wrote:
| Okay so everything I said is apparently already a much more
| thought out rant
| Sholmesy wrote:
| I've never disagreed with something more.
|
| > On the other hand, something that's cute will be far more
| memorable and much easier to say.
|
| Citation needed?
|
| How is <random-fairy-dust-word> easier to associate with "Ingest,
| Processing, & Storage of Thing" than <thing-etl-service>?
|
| EDIT: On closer inspection, I think this is intentional HN rage
| bait.
| surement wrote:
| > EDIT: On closer inspection, I think this is intentional HN
| rage bait.
|
| do flag stories like this
| tauwauwau wrote:
| I think we are mixing two different scopes in the the discussion
| here. If you are naming a company or a product that will be
| offered to clients, name it something unique that'll appear in
| searches. However, if you're writing a piece of software that's
| not going to go outside the company, having descriptive name is
| the way to go.
|
| You can even name your products with generic descriptive names,
| if your company's name is unique enough, then that'll act as a
| namespace for product with generic names. Think of packages in
| Java, C#, we don't debate about that we have to use a cute name
| for a X.java or X.CS, because that problem has already been
| solved by namespaces.
|
| Product name Excel and Office works for Microsoft because that
| "Microsoft" acts as namespace and "Microsoft Office" and
| "Microsoft Excel" are unique enough to be fully qualified names.
|
| The ntietz entry is talking about using cute names for internal
| services, which is very bad idea. Please enjoy
| https://www.youtube.com/watch?v=y8OnoxKotPQ
| m_mueller wrote:
| IMO there is a middle ground: larger & long living services
| that are internal only, and you have 1-2 handful of them. At my
| current employer I've started with greek gods whose background
| is related with the service we're building. E.g. Apollo = god
| of truth = data warehouse; Hermes = messenger god = messaging
| service for reporting, etc. It's quite successful in that these
| names are more quickly adopted and recognized by internal
| business users, compared to giving it a boring functional name.
| It also clearly outlines that they are part of a wider concept
| (new tech stack = greek gods, legacy marked for decommissioning
| = mostly everything else they hear).
| leokennis wrote:
| The issue is, if you create an internal tool that allows you to
| order printer paper for your departments printer you might name
| it "PaperSupplier": https://papersupplier.acme.com. If it
| doesn't work, just send a mail to papersupplier@acme.com!
|
| And it works so well, the company now also wants employees to
| order staples and hole punchers through it.
|
| What do you do now?
|
| Are you going to rename the tool, change the address, change
| the e-mail?
|
| Or is your company now going to have you order your staples
| through "https://papersupplier.acme.com"?
|
| We all know it's the second.
|
| My strategy would be to go for very generic names: even though
| it (initially) only allows you to order paper, name it
| "Internal Supply Portal" or something.
| tauwauwau wrote:
| You are right that function may evolve over time and name may
| not be completely accurate but it's still partially accurate
| opposed to being being completely inaccurate. In your example
| papersupplier, I would want to create a new site for staples
| or better create a new site for all categories of stationary
| instead of modifying the old one.
|
| I like the idea of having a generic but still descriptive
| name.
| daviesgeek wrote:
| I couldn't disagree more for service and infrastructure names.
|
| > And I think this applies more broadly to projects and
| companies, too.
|
| Customer facing names are fine, they should contain a bit of
| whimsy and cuteness. Obviously if you ship "payment-processor-
| gateway-v2" to the customer, that's not a great name for a
| company, product, or feature. Projects also make sense (mostly),
| though they suffer from some of the same issues I'm about to
| outline.
|
| However, for internal names like for services, adding cuteness is
| a horrible idea.
|
| > A well-factored service will generally have a tight set of
| responsibilities which make sense together, and this makes a
| descriptive name very appealing.
|
| Descriptive names should help box in the scope of the service. If
| the payment processing service is also doing AI processing on
| user avatars, you might want to think about breaking that out
| into a separate service. With cute names, scope can grow
| infinitely because there's no inherent description attached to
| the name. You may have "Athena" doing one thing but as things
| progress and the company/software grows, it'll be taking on 17
| other responsibilities. Instead if it's named "backend" or
| "payment processor", it's clear in the name what it is and the
| scope of the project or service.
|
| Then there's the problem of an engineer's mental overhead.
| Newcomers have to learn what all the cute whimsical names mean.
| You have to keep an internal dictionary and someone has to make
| sure it stays up to date. (Spoiler: It won't ever be up to date.)
| I could have filled at least two pages with all the acronyms and
| whimsical names from one of my old jobs and it was always an ever
| changing landscape. If a service is named succinctly and clearly,
| the engineer doesn't ever have to think about what that
| particular service is or does. I understand there's going to be
| some edge cases where the name doesn't cover everything, but
| that's certainly better than the case where the name doesn't
| cover any of the description of the service.
|
| > It's impossible to predict with certainty how your software's
| requirements will evolve over time.
|
| Then within the scope of the new requirements, changing the
| service's name should be inherent in the discussion. IMO, this is
| a sign of some bad engineering processes. One shouldn't be
| worrying about names in the future if you've named something
| correctly for the current scope. If it changes, address it then.
| Most modern languages will let you easily refactor a name. By
| those standards, you shouldn't build the software, since it might
| change over time and we don't want to make assumptions about
| whether we'll still be using Mongo or if MYSQL makes a comeback.
| We can't make those decisions because we can't predict with
| certainty...you see the trap you can easily so easily fall into?
|
| One thing that's also a huge challenge is pronunciation. Someone
| will pronounce one of those cute names in a way that no one else
| has heard, it'll take a minute to sort out, and, while it did get
| sorted, it took some time. Multiply that out over weeks, months,
| and years for every engineer and it can get costly. I understand
| that descriptive names can also be mispronounced, but since
| they're common (to our industry), it's easier to sort out.
|
| I definitely do understand the sentiment behind adding some fun.
| I'm not here to kill the fun atmosphere of a new startup who
| wants to be cute about their names, but I've seen it play out
| very poorly over a long time when the
| company/projects/services/team grows and it's not pretty.
|
| Stick with descriptive names. You and everyone else will remember
| them easier and you'll save time, giving you the time to go have
| some fun and grab a couple drinks with coworkers.
|
| (I also published this here: https://memos.daviesgeek.com/m/4 for
| a little better formatting and to keep this comment around for
| myself)
| twawaaay wrote:
| I think names should first of all be _reliable_.
|
| What I mean by reliable?
|
| * It does not change either in time or space -- you have to come
| up with a good name right from the start and then you are not
| allowed to change it. The same thing has to be named the same way
| throughout the system and ideally through multiple connected
| systems.
|
| * It must not mislead -- the name does not have to be super
| descriptive (although it is a desired property) but it cannot
| cause you to think the thing does something it doesn't do.
|
| * It must be unique -- the same name cannot be used for different
| similar or dissimilar things.
| kevincox wrote:
| Your list is very similar to mine:
| https://kevincox.ca/2021/03/23/good-names/
|
| I agree. The uniqueness and stability of a name is key. Then
| making is not mislead is good. Then being descriptive is nice.
|
| I think the article is hitting on descriptive names can become
| misleading over time. People will think that a descriptive name
| is helpful, even if it was poorly chosen or is no longer
| accurate.
| nightowl_games wrote:
| I agree. Right now I'm working on a service called simply
| 'backend'. We are adding some environment variables to it, and
| I'd like to prefix them with something relatively unique.
| BACKEND_DATABASE_ADDRESS is simply not unique enough to pollute
| the environment with. I know this example isnt perfect (and no
| were not even writing these env variables to the user's shell),
| but it demonstrates the lack of identity.
| meindnoch wrote:
| This trend is so painfully cringey...
| arichard123 wrote:
| Are we short on good words to describe the moving parts of our
| systems? We use so many synonyms for "thing" that then get
| overloaded.
|
| Do we not just need to invent some new words with specific and
| useful meanings?
|
| I'm not sure where the different lines would be drawn. Perhaps
| thinking about a specific program might be helpful. This can't be
| new thinking can it.
|
| What naming conventions do people use that aren't obvious but are
| useful?
| grahar64 wrote:
| The word "transaction" is so overloaded it would be pointless
| to use in a system. At a previous company we had to have a
| glossary of words that you could use instead just so the
| documentation made sense.
| suyash wrote:
| Horrible advise in this post, names should be
| DESCRIPTIVE/MEANINGFUL because a critical rule of marketing says
| that provide solutions to people who are already looking for it.
| Therefore if you want your service/product to show up on
| SEO/Search, use descriptive name and not a cute name that no one
| knows what it means.
| wellpast wrote:
| For broad services and product lines, this is 100% correct.
|
| Change is inevitable and having a simple (cute) name allows
| collective semantics to float with reality as it changes.
|
| Of course for less volatile components, descriptive is useful,
| almost necessary.
|
| One of the most important skill sets in putting together
| technical systems is understanding the difference between
| volatile vs stable components.
|
| The problem I've found is that so many technical people can't
| fathom change or see where change is inevitable. So they operate
| as if _everything_ is stable.
|
| That's why you see so much pushback against the idea proposed
| here.
| Arch-TK wrote:
| I name all my machines after a theme, unlike a major organisation
| I don't have the money to have dns-server-0 and dns-server-1
| which ONLY host an authoritative pair of DNS servers and then
| web-server-0 which ONLY hosts my website etc etc.
|
| But if you can guarantee that something will continue to be one
| thing for ever and ever, I think maybe a descriptive name can
| work. It really depends on what level of analysis you're working
| on. Services probably shouldn't change their core purpose over-
| time, but business pressures may result in them changing their
| core purpose.
| cryptonector wrote:
| Names of products should be memorable, and probably cute.
|
| Names of technical items (e.g., function names) should be
| descriptive.
| trimethylpurine wrote:
| It seems to me that you have bigger problems than nomenclature.
| Do you add comments to your code? That's because you're part of a
| team. When you add function it should go in a separate package.
| Again, you're part of a team.
| sirsinsalot wrote:
| I refuse to ever use homebrew because all the themed naming makes
| me rage.
|
| It is nonsense.
| xvilka wrote:
| Or use names of Lovecraftian deities. It better resembles the
| spirit of the industry.
| erikpukinskis wrote:
| Lots of people pointing out how bad this is for new hires, but
| it's not just a hurdle for new hires to get over... in a lot of
| cases people will just _never get over the hurdle_. The
| discussions outside their team will just be a bunch of
| gobbledygook that they tune out. And years down the line you end
| up with a really Balkanized engineering culture. Where you know
| what happens in Zeus, but you have basically blocked out
| Persephone, Ulysses, and Palmyra because they are another team's
| responsibility.
|
| Maybe that's actually a good thing for some organizations, I know
| many CTOs spend most of their time trying to make cleaner
| separations between teams.
|
| But if you want a culture where people understand and evolve the
| larger architecture from time to time, cute names are going to
| make that less likely.
| pbnsh wrote:
| [flagged]
| someweirdperson wrote:
| > ! NEVER USE CUTE NAMES IN ANYTHING !
|
| So I guess you first-born is called pants-pooper?
| pbnsh wrote:
| No, I address them as child01-mother01, child02-mother01,
| child03-mother02 and so on.
| f4c39012 wrote:
| How are their grandparents addressed?
| bryanrasmussen wrote:
| I like to prepend with year of birth.
| once_inc wrote:
| Leave cutesy and or funny names for instances of software, not
| the software itself. You can have a complicated java program with
| dozens of classes and high levels of abstraction all named with
| the usual 'boring' names, and run an instance of that class an
| have it called r2d2, ultron, or "An Eridean named Rocky". That
| antropomorphizes the program, which leads to higher acceptance
| and easier internal communications.
| MrGilbert wrote:
| I wouldn't necessarily call them cute, but "Odin" (my phone),
| "Tyr" (my NAS) and "Thor" (my home server) would surely agree.
| knorker wrote:
| Cute names don't scale.
|
| You can name your servers after star trek characters, and
| routers after star wars characters, only if you have very few.
| MrGilbert wrote:
| Sure, yes - something that's not an issue at my home, but
| surely will at other places.
|
| Regarding naming - Middle Earth should have many possible
| names at hand.
| knorker wrote:
| Star trek has many names too. It's just that they get more
| and more obscure.
|
| Which is fine if it's just you. But if it's a company and
| you hire someone who doesn't rewatch TNG every weekend,
| then it doesn't help that _you_ know the daud 's wife's
| name.
|
| And that would hurt the business.
|
| I'm sure every character in the star wars cantina has a
| name. That's not the point.
| fragmede wrote:
| Three great unsolved problems in computer science are naming
| things and off by one errors.
| FeepingCreature wrote:
| > I don't want to be the one to advocate for delaying features so
| we can rename broadcast-service to broadcast-and-new-
| responsibility-service. That's going to be an unpleasant
| conversation with your product manager, for good reason: Because
| this never should have happened, and it's a waste of time to
| change the name.
|
| Sounds like there's a workflow problem around renaming services?
| tabreu wrote:
| I love this.
|
| Another issue I have with descriptive names is that wrappers and
| other components quickly get out of hand, then you have machine-
| learning-worker-wrapper-utils and conversations about this become
| impossible.
|
| Someone argued that cutesy name hides the responsibility;
| Personally, I think the effort of resisting making cutesy name do
| stuff it wasn't originally designed to do is well worth the ease
| with which you discuss these now concisely named components.
| paxys wrote:
| It's funny that the author brings up the point about names being
| for identity rather than responsibility. Historically, names have
| often signified both. Ask anyone called Smith or Cook or Archer.
| extr wrote:
| Nice theory. In practice all this does is make it harder to
| onboard new people. Quick test: It's your 2nd week on the job.
| Some core system just went down, and you've been assigned to
| figure out what service is causing the trouble. What makes for
| easier, more transparent reading of error logs, the name
| "ServiceRouter", or the name "Trainstation"? It's not just a
| matter of the name being perfectly descriptive for any and all
| responsibilities, in zero-context situations it can be good just
| to give a hint that yes, this is a service, and yes, it at one
| point handled routing, so it seems like an okay place to start.
| The more obscure the name, the longer I spend reading about some
| obscure same-named repository and wondering how it's related to
| the issue at hand.
|
| That said, I think a certain degree of whimsy is definitely
| acceptable (necessary?) in the workplace and should be
| encouraged. I can support silly names for the sake of having fun.
| But maybe if it's something important, foundational, try to
| remember it may not be as fun for someone 5 years down the line
| at 2AM.
| doctor_eval wrote:
| Who would assign a core system failure resolution task to a
| newbie who's been there two weeks?
|
| Also, per the article, the problem is that "ServiceRouter"
| maybe isn't as obvious as you might think. The actual HTTP
| routing might be done by "HttpPathInspector". "ServiceRouter"
| is actually a non-core message router for analytics.
|
| Naming is hard.
| ilyt wrote:
| > That makes for easier, more transparent reading of error
| logs, the name "ServiceRouter", or the name "Trainstation"?
|
| What service ? Routing it where? The "descriptive" here isn't
| describing anything useful.
|
| "OrderBaseket" is descriptive. "sso-portal" is descriptive.
| "ServiceRouter" just uses few related words to the job. My blog
| is also "serviceRouter"...
| xlii wrote:
| I've been in situation where "ServiceRouter" was also doing
| feature flagging so when debugging 5-year old impossible to
| solve issue no one looked at it (because, well, it was
| ServiceRouter not ServiceRouterAndFeatureFlaggerAppendage, in
| spirit of the article) - YMMV.
|
| Another fun story I recall happened when server technician had
| to replace faulty HDD in RAID array. We ensured that the serial
| numbers were correct in correspondence yet still technician
| replaced the wrong one. When we complained we got into funny
| argument that we should use color code to designate HDD. Serial
| numbers are hard to pass and easy to confuse (especially since
| they were next to each other). But color coding wasn't provided
| to us, customers - we couldn't use it even if we wanted to.
|
| Naming is hard but descriptive name doesn't guarantee
| correctness or helpfulness just as non-descriptive wont ease
| understanding or improve communication without proper directory
| or conceptual mapping. Does DatabaseServer-EU-259-aed6f give
| more information than "dumpstation" in scenario where it
| relates to single server wordpress blog.
|
| In the end it's still about difficulty of naming, middle ground
| and consistence. Ubuntu for years used letter coding with
| animals and it worked. MacOS uses naming scheme for releases
| even though iOS and iPadOS are numbered only. Some people would
| be confused that Windows 95 is after Windows 3.11 and before
| Windows 10 and Windows 11. Not sure if Docker still use cutesy
| auto generated names for containers but it was fun to use.
|
| Naming is hard.
| gorgoiler wrote:
| They're both right, of course -- the author and his colleague --
| and this blog post makes an excellent point as to why.
|
| I will switch from descriptive to cute once I've reached a
| certain level of abstraction. That level can best be defined as
| the level where I will need to start advocating for the idea with
| other engineers.
|
| A new ssh wrapper for automating access to the manufacturing
| robots? _example.factory.sshtool_
|
| A log file parser for extracting text-only errors across multiple
| robot.log lines into structured error objects?
| _example.factory.logs_
|
| A quarter-long project to build a new abstraction over all our
| thirteen different categories of manufacturing robot we have
| deployed on site that replaces a bunch of shell scripts written
| by the former CTO, and then actually replace all those shell
| scripts with the new thing, with tests?
| _example.factory.duckling_
|
| I'd promote it as being named after how ducks imprint on their
| mother and follow her lead. Kind of a nod to the robots, but also
| to the former CTO. Cute names can feel a little saccharine but it
| really helps build advocacy obviously -- it's ultimately a
| branding / marketing exercise.
|
| If you do that day-in day-out at the level of the ssh tool or the
| log parser -- projects that should ideally have a low level of
| controversy compared to the shell script rewrite -- then people
| are going to get annoyed with you.
| anchochilis wrote:
| I think the author has a point here. In an ideal world, we would
| of course spin up a new microservice every time a PR in the
| foobar-widget-generator service begins to deviate from generating
| foobar widgets. In practice, we make delivery tradeoffs all the
| time. It's not at all uncommon for service scope to creep while a
| new, urgent feature is being experimented with. And launching a
| new service is never, ever going to be as cheap as updating an
| existing, well-maintained one.
|
| My own hard-line requirement when it comes to naming services is
| that they should be a single word with some relationship to the
| service's purpose. Ideally a common English word, but proper
| nouns are permitted if they improve clarity. Brevity must ALWAYS
| take precedence over clarity. There's only so much you can
| express in a name anyway; a detailed explanation of exactly what
| a service does should exist in documentation.
|
| Otherwise you end up with long names like "horizon-blob-profile-
| server" or "batch-process-execution-engine". Multiple words lead
| to ambiguity. Inevitably you end up using dashes, camel case,
| underscores, or no differentiation at all in order to represent
| word boundaries in different systems, because VCS, filesytems,
| domain names, and cloud systems all have different sets of
| permitted characters. This makes automating your infrastructure
| painful.
|
| And of course people resort to acronyms when discussing the
| services, which means everyone is forever getting the dfkg
| service confused with dkfg. "Whoops, I deleted the wrong
| database!"
| allknowingfrog wrote:
| I have this exact regret. Code may be meaningless, but acronyms
| are both meaningless and confusable.
| mastermedo wrote:
| When a bunch of those names accumulate, you pay a high onboarding
| price, not only for newcomers, but also for people who don't read
| your changelog.
|
| - Oh, _gfuby_ can now monitor my instance in production in
| addition to being a code versioning system!?
| kpz6 wrote:
| > I don't want my services or projects to sound like a law firm
| ("Ingest, Processing, & Storage LLP").
|
| That would actually be a fun name.
| l3uwin wrote:
| [dead]
| furyofantares wrote:
| I kinda wanted to agree with the author because of the number of
| times I've encountered and X-Yer that's neither X nor Y anymore.
|
| But honestly even in those cases it's still usually somewhat
| informative despite the argument that it's misleading. It's still
| got some essence to it, and having a clue about the history is
| also often useful.
|
| And it's frequently abbreviated XanYat or some such, or
| initialized the XY, which is just treated as any old name anyway
| and not a description. It's not cute or fun, and maybe less
| memorable (not sure about that, a single cute name is memorable
| but an ocean of them sounds confusing).
| eliasffyksen wrote:
| I like descriptive names that fade. It provides a sort of local
| etymology. Maybe not good for business, but definitly provides
| some interesting discussions at the pub.
| kerkeslager wrote:
| It sounds like this idea makes _some_ sense in the context of
| having made a large number of mistakes already, but the real
| answer is, _don 't let it get that bad_. The author strikes me as
| having worked only at companies that are so dysfunctional that
| they have never seen what a functioning team looks like.
|
| It starts going downhill here:
|
| > Trouble is, names are hard to change.
|
| Uh, why? They _shouldn 't_ be. It should be a find/replace on
| text, with tests to catch any issues. The essay later goes on to
| talk about people using the name... but that doesn't matter,
| because the code is the self-checking source of truth.
|
| Additionally, name changes should be rare if you did your job
| right the first time.
|
| > A well-factored service will generally have a tight set of
| responsibilities which make sense together, and this makes a
| descriptive name very appealing.
|
| No. Wrong. A well-factored service has ONE responsibility.
| Period. Not "responsibilities", "responsibility".
|
| This is what I mean when I say that a name change should be rare
| if you did your job right the first time. If a service has
| multiple responsibilities, you don't need to change the name,
| because you aren't adding or removing responsibilities. If you no
| longer need what the service does, the service can stop existing.
| And if you need something new, you create a new service.
|
| And yes, sometimes performance means that you want to chunk stuff
| together, and strictly passing every different task over the
| network bus will cause your application to grind to a halt.
| That's more a criticism of the weird assumption that passing
| things over the network is necessary for encapsulation than of
| the single-responsibility principle, however. If your services
| are tightly coupled to separate network requests, you're going to
| experience pain no matter what you do. One of the first things a
| microservices architecture should do is abstract away the network
| so that from the caller's perspective, they don't know whether
| calling a service is making a network request or calling a
| library.
|
| > I don't want to be the one to advocate for delaying features so
| we can rename broadcast-service to broadcast-and-new-
| responsibility-service. That's going to be an unpleasant
| conversation with your product manager, for good reason: Because
| this never should have happened, and it's a waste of time to
| change the name.
|
| Agreed, because a) broadcast-service is a pretty vague name and
| b) new-responsibility should be its own new-responsibility-
| service.
| amarant wrote:
| Surely this is satire.... Right? Right?
| Lapsa wrote:
| has to be
| pipeline_peak wrote:
| > The world is boring enough as is. Let's add more whimsy and
| cuteness through our service and project names.
|
| Cute names suck, a list of them obfuscates a development stack to
| newcomers and they're just hard to take seriously. At my company,
| we have Jira, SumoDB, and Java. I wonder what that means to a
| Business Analyst, surely they know straight away.
|
| The hipsterdom in the tech world is cringe. Go teach (force) your
| kids to learn Python with the children's book you wrote. Oh and
| don't forget to give it a cute name that sounds Japanese or like
| a type of tea, we need more of those...We're totally not going to
| look back on cute names in 20 years as a silly fad
| Shank wrote:
| At my company, we have an app called "rails app". It's the main
| app we have, and it's hosted in rails. Makes for some interesting
| discussions about what rails is truly capable of, what features
| are rails features or are rails features, etc.
| __MatrixMan__ wrote:
| I agree with this. Where I work, one team has given descriptive
| names to everything and several other teams have then shortened
| them inconsistently. So it's tribal knowledge that "cloud" and
| "gen2" are the same thing, and software/platform/gen1 are almost
| the same thing, but configured differently.
|
| If we had called them Frank and Susan, we'd know what each other
| means.
| surement wrote:
| if your solution to overly generic names is names that are
| meaningless without context, you probably have bigger problems
| ppeetteerr wrote:
| While scope expansion is a potential issue, a service by its
| nature should not inherit scope outside of its core
| responsibility. If it does (an auth service with some type of
| user information is clearly taking on more scope than it should),
| a practical name will reveal that right away.
|
| The issues with practical names mentioned in this article are
| pretty small when compared to the very real issue of
| understanding cute-named services. If AuthService goes down, I
| know what that means. If Balthasar goes down, I now have to
| understand what that is, look up documentation, find the right
| team, etc.
| the_af wrote:
| It seems the author correctly points out some problems with
| descriptive names, but then advocates for "fun" names without
| explaining how they deal with the problems. So the solution is
| that they are "more fun" and give up on solving the problems
| whatsoever?
|
| I've dealt with cute names in past jobs. Because they are
| meaningless ("Thoth"? I think that's an Egyptian god, but what
| does it _do_?) I 've spent months confused. And when I didn't
| deal with them, I forgot what they did, especially since in the
| microservices world there's so many of them.
|
| I'd rather have a slightly outdated but descriptive name than a
| completely meaningless "cute" name.
| SideburnsOfDoom wrote:
| Title is wrong, should be "Thank You Mario, But Princess Peach Is
| in Another Castle!"
|
| /s
|
| If you disagree with that, then maybe you are in favour of
| descriptive, not cute, names after all.
|
| I really thought that we had moved past this "cute pop culture
| reference naming" idea, but here it comes back again. Just no.
| rk06 wrote:
| Why not have two names? Canonical (descriptive) and a code name
| for referring.
|
| I am all for Descriptive names, but they tend to be long and hard
| for uninitiated to pronounce or remember correctly
| ChintanGhate wrote:
| Go for boring descriptive names that create a cute acronym. Win-
| Win!
| sublinear wrote:
| I only agree if I'm allowed to reinterpret "cute" as easily
| recognized uniqueness.
|
| The motivation for cuteness seems to be a spiteful false
| equivalence made between unintentionally bad names and
| deliberately silly names.
|
| Good names come from well organized projects.
|
| It's sad to hear some would rather name their servers after
| dolphin species than address the communication problems on a
| team.
| r_hoods_ghost wrote:
| Cute names often (not always) rely on a specific cultural context
| that many devs in the present, and definitely many devs five
| years down the line, won't share. When people argue for "cute"
| names over "descriptive" names, what they really often mean is
| "names that are actually descriptive but only if you understand
| my obscure nerd joke / spent your childhood playing pokemon". Or
| they pick a theme and end up trying to stick with it and make
| something vaguely, but not really descriptive within that theme.
| It also makes searching for internal documentation a nightmare.
| quickthrower2 wrote:
| I disagree because if your machine learning service, Rudolph, has
| become a load balancer, you have bigger problems!
|
| You can create a new service to do the new thing!
|
| IaC might make it easier to rename stuff anyway but not everyone
| does that.
| rhacker wrote:
| While I don't agree with the author AT ALL. I think products need
| two names: a marketing name and a code name. I was at a company
| that kept renaming the marketing name. And for some reason I
| couldn't get the programmers to stop spending weeks redoing
| packages: com.companyname.integrationhub to
| com.companyname.superconnector.
|
| I kept trying to tell people that the marketing name is going to
| change all the time and that the package we put it under should
| be very different from the marketing name - on purpose, so that
| we don't need to repackage it every 2 weeks. Call it
| com.companyname.dataintegrator. The marketing name of the data
| integrator can change all day long and its package must remain
| dataintegrator.
| wruza wrote:
| I mostly agree, although from a user side it's sometimes
| confusing to encounter random identifiers barely mentioned
| anywhere.
| jcampbell1 wrote:
| Last time I did iOS stuff, coding around iCloud everything
| was called UbiquityContainers or something.
| banku_brougham wrote:
| as long as they were ubiquitous and containers I have no
| objection.
| aendruk wrote:
| I tried this once and marketing latched on to my deliberately
| stupid code name and used it for the public release. My protest
| was unable to sway them.
| dlivingston wrote:
| If comfortable disclosing, what was said code name?
| kevincox wrote:
| 100%. I was at a company and they kept renaming the internal
| name to match the marketing name. We had 3 names for some older
| tech and 2 names for the less than a year old service. I
| strongly recommended that we should adopt the original name as
| a "codename" and use it for code and internal technical
| documents.
|
| Marketing should absolutely have full control over the user
| visible name. But technology has different needs where a
| "codename" is a much better match. Having two names is
| generally only a tiny bit confusing.
|
| I have also yet to see a codebase rename that completes before
| the product name changes again. You always just end up with a
| confusing slew of N names in the codebase if you try to rename.
| pphysch wrote:
| It seems that most business objects should have all of the
| following:
|
| 1) A memory-friendly, indexed, unique, immutable ID (e.g.
| BIGINT or GUID).
|
| 2) A human-friendly unique immutable codename/slug.
|
| 3) A human-friendly mutable marketing/display name.
|
| 1 & 2 could be combined in some cases
| dlivingston wrote:
| Related-ish, but Apple's macOS APIs are peppered with
| references to NeXTSTEP. I find this charming. For example,
| NSView (spelled out - NextStepView).
|
| https://developer.apple.com/documentation/appkit/nsview
| aaronbrethorst wrote:
| NeXTStep used "NX" prefixes, and its successor, OpenStep,
| used the prefix "NS". "NX" stood for "NeXT", "NS" stood for
| "NeXT and Sun".
|
| https://news.ycombinator.com/item?id=15973609
| dlivingston wrote:
| The comments on your linked post seem to indicate that NS
| referring to "NeXT & Sun" is highly controversial.
| spfzero wrote:
| IIRC the NS prefix was in use long before there were any
| dealings with Sun. There was software development going
| on at NeXT before they had the name for the OS
| ("NeXTStep"). So, NX for NeXT, NS for NeXTStep.
| pengaru wrote:
| > And for some reason I couldn't get the programmers to stop
| spending weeks redoing packages: com.companyname.integrationhub
| to com.companyname.superconnector.
|
| I wonder how much open offices comingling
| sales/marketing/engineering has contributed to this kind of
| dysfunctional crossing the streams.
| banku_brougham wrote:
| This is not an effective argument in disagreement with the OP.
| layer8 wrote:
| I don't think it was supposed to be, given the introductory
| "while".
| kodah wrote:
| > A well-factored service will generally have a tight set of
| responsibilities which make sense together, and this makes a
| descriptive name very appealing. Your service which started with
| a nice, tidy set of responsibilities may start to shift over
| time. And then you're faced with a choice: keep the old
| descriptive-but-now-wrong name, or put in all the effort to
| change it.
|
| I had this happen recently. We wrote an application with two
| major components: one that processes events and repackages them
| as generic events and a component that receives those events and
| schedules work. We work in a compliance heavy environment so the
| architecture often reflects a separation of concerns given the
| information being processed.
|
| The scheduler became pretty popular for people to plug into, even
| if they didn't use our other component. The scheduler eventually
| left the nest of our small, purpose-built program and became
| general infrastructure. It's now the "SecureScheduler", though on
| our component diagrams it simply goes by "scheduler".
|
| My lesson learned was that if you properly separate an
| application out, the component names can become independent
| software in the service registry over time if they need to. The
| scheduler is pretty strictly scoped, so it'll never start doing
| new zaney things. It simply schedules work in a controlled
| environment.
|
| These arguments over cute and functional names, I think, are a
| byproduct of a couple failures:
|
| - Properly naming and confining components role within a single
| service. Our scheduler was generic enough to operate on its own,
| but it's role within our architecture was pretty confined. It's
| main optimization compared to other software like it was the
| inbound communication and authentication flows that made it easy
| to securely plug into.
|
| - Lack of organization and vision at the service registry level.
| The scheduler didn't need a vastly different name, because it's
| purpose didn't really change. It did one thing and it did that
| one thing exceedingly well. There was a hole in the wider service
| registry that it could fill. As a result it was elevated to its
| own program in the service registry with its own deployment
| schedule.
| andix wrote:
| So how do you call your services? Harry, Ron, Hermione and
| Voldemort?
| pwinnski wrote:
| If the reason for this is that it's hard to change names, then
| the solution is to make it easier to change names, not to use
| stupid names. A given service should run on hardware/VMs that are
| named related to that service, and if the service goes offline,
| so does that hardware or those VMs, to be repurposed (and
| renamed) into something else.
|
| Anything else leads to madness, or starts from madness.
| throwawaaarrgh wrote:
| As an example of the author's idea in practice, imagine a car,
| where every part in the car had a cute name, and every car in the
| world had different cute names. Now imagine being a mechanic. Or
| going to work for a new car company. Or just being in _analytics_
| and trying to understand how to work with the product. Or being a
| customer trying to understand how your new car works.
|
| A part named after its technical role/purpose shouldn't need to
| be renamed. If its purpose has changed, you have a different
| service. Without renaming it, are you talking about OLD cutename,
| or NEW cutename? Or NEW-NEW cutename? Major version numbers help
| here, for any kind of name.
|
| Sometimes names are too generic, like "web", or "auth". New
| services can be named something more specific to be more
| distinct.
|
| Things named after parts of the organization always get renamed,
| so always avoid that. No team names, org names, business specific
| monikers, etc.
|
| And the whole idea of code-as-docs is that your code is
| descriptive enough that you don't need to pepper tons of comments
| through the code to understand what it's doing. The same can be
| applied to architectural components like service and server
| names.
|
| But you know what? If you really feel that strongly about it? Go
| ahead and use cute names. For _your_ service. The rest of us will
| be using boring names, and yours will be the odd service out,
| because you don 't get to tell the entire team/business what to
| do by fiat (unless you're a horrible micromanager).
| Aaargh20318 wrote:
| The author is not talking about the individual parts though,
| they are talking about entire services. So basically products
| or maybe large modules.
|
| To use your car analogy: It's the Ford Mustang, not the Ford
| goes-really-fast-as-long-as-you're-not-taking-any-corners-
| sporty-car
| throwawaaarrgh wrote:
| Read their first two paragraphs again. They're talking about
| individual services (and so am I). Steeringwheel-svc,
| Rackandpinion-svc, Shifter-svc, Engine-svc, Transmission-svc,
| Axle-svc, Tire-svc. Same as filetransfer-frontend-svc,
| filetransfer-batchloader-svc, filetransfer-batchtransform-
| svc, filetransfer-db, etc. (those names might still be too
| generic, but at least you know what I've just described)
| fexecve wrote:
| Baby, meet bathwater. "Names are hard to change" is supposedly
| the reason to give things meaningless random names. Great, now
| you get the worst of both worlds, the meaningless name is now
| synonymous with a purpose (the very thing you tried to avoid,
| well, tough luck, that's not how human psychology works!) AND
| newcomers to the company/org will have zero idea what "galactus"
| and "goatpen" are or what they do.
| lifeisstillgood wrote:
| Interesting, cute even. But I will stick with boring law firm
| names.
|
| Firstly when I was a so-called manager cute project names were a
| nightmare - who could remember what "project mayhem" was - lift
| and shift half the the data centre or was it refactoring the
| stupid accounts hack. Project refactor-accounts-monthly-charge is
| something at exec level everyone can remember. It's fine for
| project-negotiate-possible-sale-of-dutch-office to be called
| project mayhem, because powerpoints get acciendetaly shared,
| emails get read, but there aren't many of those.
|
| Secondly Sam used to be called Sam Smith because he was the
| smith. If he becomes used for something else people will create a
| directory (in their heads or in reality). And that's the key
| here.
|
| Directory services are way easier to manage
| shp0ngle wrote:
| What's a better name. "Epiphany" or "GNOME Web"?
|
| Everyone calls it Epiphany anyway.
|
| So yeah I agree.
| brabel wrote:
| The argument has convinced me, even though I thought it was
| crazy, initially.
|
| Very good points and for many things, I think this applied very
| well.
| whoisthemachine wrote:
| > It's impossible to predict with certainty how your software's
| requirements will evolve over time. And if you don't know what
| your software will need to do later, you don't know what the
| ideal factoring will be then, let alone now. It will almost
| certainly change over time.
|
| If you follow the idea of the "Single Responsibility Principal"
| with discipline, then you should create a new piece of software
| if changes to it would drift too much from what it was named. If
| you have a lawn mower and you start trying to use it as a mulcher
| as well, you will be a lot better off creating a new product
| called a "mulcher" intended for just that purpose.
| lioeters wrote:
| ..Or create a new product with a standard connector for both,
| an adaptor for lawn mower and another one for mulcher, using
| the same engine. It can be called Mulchwer - cute _and_
| descriptive! When the company inevitably invents a new adaptor,
| say a snow blower for clearing the sidewalk, the product can be
| renamed Mulchwer X, or Multi-Mulchwer Deluxe. It 's now an all-
| purpose product with a set of adaptors for any front/backyard
| needs. It will also be a subscription-based business model,
| always needs to be connected to the Internet, and have machine
| learning for full self-driving.
| whoisthemachine wrote:
| We call these tractors, although the adapter is usually on
| the rear! And I think they are gaining some AI.
| ppqqrr wrote:
| False dichotomy; descriptive names can and should be cute, if
| you're willing to spice them with a bit of analogy and/or irony.
| Problem is that most corporate programmers lack personality (and
| punk spirit, tbh), and use names as a way to make their code
| appear "compliant," (boring) deflecting attention and scrutiny
| from their work.
| fckgnad wrote:
| I disagree. But cute is better than a fucking acronym. Never
| never never use acronyms or one letter variable names.
| reassembled wrote:
| What annoys me is when internal code names are used all over the
| place throughout the code base. Sure it might make it easier for
| those steeped in years of company culture to navigate the code,
| and provide a slightly more playful company culture, but it makes
| it an absolute nightmare for a beginner to find things.
|
| Furthermore, I often see companies use trademarked words for
| internal code names, which could lead to problems if their usage
| is leaked outside the company. I can't remember what it was but I
| recall reading that such use of trademarks for internal code
| names led to legal issues for a company.
| dctoedt wrote:
| > _I recall reading that such use of trademarks for internal
| code names led to legal issues for a company._
|
| Apple Macintosh, perhaps?
|
| https://www.macworld.com/article/669214/how-the-macintosh-go...
| nibbleshifter wrote:
| I've flipped between these two positions (descriptive and... not
| descriptive) names.
|
| I settled on nondescript and just mash two random words together
| when making a new project.
|
| ~90% of my actual work projects are less than 10 files of source
| code anyway (not counting dependencies, readme, make file,
| requirements.txt, etc). The vast majority are one file Python or
| Bash scripts.
| gloosx wrote:
| My favourite:
|
| status: Enum<0,1,2,3,4,5,6,7,8,9> // 0-kitties, 1-puppies, rest
| in Confluence
| kdamica wrote:
| IIRC at one point at Uber there were three completely separate
| services named Polaris.
| Waterluvian wrote:
| Help me, for I am socially malnourished. This is a joke, right?
| eightturn wrote:
| i guess I'll just let VidaliaOnions.com expire then ... :/
| dbingham wrote:
| You're optimizing for the wrong things and working with an
| artificially limited set of constraints.
|
| The rule of thumb is that we spend 10x the amount of time reading
| code that we do writing it. When you use cute names to avoid the
| pain of name changes when the service changes, you're optimizing
| for writing over reading. It's a mistake. You pay the cost of a
| name change once, but you pay the cost of an unclear name many,
| many times per day.
|
| Further, you're introducing unnecessary, artificial constraints.
| If you need to add new responsibilities to a service that don't
| fit with in it's existing scope - the correct answer is to make a
| new service.
|
| Granted, some times we don't have time for either a rename or a
| new service and we have to duct tape the functionality wherever
| we can. This is called techdebt. It should be documented,
| tracked, and paid down at a later date... By renaming the service
| or refactoring out a new one.
|
| Attaching arbitrary functionality on to cutely named services
| that don't have logical coherence is not future proofing. It's
| really bad software design.
| grahar64 wrote:
| If you work at a company for more than a week you will get used
| to the names of services and what they do.
|
| But if the name of a service becomes a lie because of changing
| requirements, then it will be an actual hinderance to
| understanding a system.
| ilyt wrote:
| > The rule of thumb is that we spend 10x the amount of time
| reading code that we do writing it. When you use cute names to
| avoid the pain of name changes when the service changes, you're
| optimizing for writing over reading. It's a mistake. You pay
| the cost of a name change once, but you pay the cost of an
| unclear name many, many times per day.
|
| That is for name of variable. Changing a name of whole
| application can be royal PITA all over the stack, if the "one
| time change" is "scour every documentation ever produced and
| change the name there too so people won't get confused.
|
| And not just docs, put the name of service as query in Grafana
| ? Gotta go around dashboards changing that too
| Hermitian909 wrote:
| This is good advice in the small, but I think the author is
| correct for larger services. I can't tell you how many times
| someone insisted on a name that was "universal such and such"
| which, uh, turned out not to be universal.
|
| More concretely, this is good advice for services that you
| expect many teams to hook into, and not great advice for
| services that you think should not expand 1-3 teams _ever_.
| dbingham wrote:
| I think the problem you're speaking to has more to do with
| attempts at "universal" design. Which actually runs counter
| to the principal that services should have a limited, clearly
| defined set of responsibilities.
| AlanSE wrote:
| This reminds me (from a long time ago) of seeing IT department
| stick names of jungle animals on computers so they can be
| recognized on the network.
|
| These days, there are many cases where _instances_ of something
| are given random "cute" names. A particular server will have a
| suitable-for-work but fun name slapped on, like "grumpy goat".
|
| Hover, I can't imagine _classes_ of something following that kind
| of naming convention. This post seems to be more about _queue_
| names or _service_ names. Software DOES intentionally use cute
| and random names for big-ticket items (see "git"). It would be
| confusing to apply this practice to more minor software, because
| it would be too many to remember.
|
| If I have a service as a part of an app that consumes data from a
| redis queue and sends it to a log collector, a fully descriptive
| name is distasteful, but I wouldn't want to name it "anteater"
| because even if my mental picture is vivid, other people will...
| not get it. I'd call it "log-passer" or something.
| xcambar wrote:
| A company I have visited had, for some obscure reason, decided
| that teams should have their own fun/memorable names. Almost 2
| years after implementation, every new hire's first comment was:
| "it's impossible to navigate the org with those names, we have no
| idea of what each team is doing".
|
| I could live with funny+descriptive, but for all that is good,
| funny only just does not work.
| grahar64 wrote:
| Yes, and we should change an entire companies culture to make a
| new hire onboard slightly faster /s
| xcambar wrote:
| In this occurrence, I couldn't measure the benefits of that
| specific element of culture.
|
| It may have been silent and powerful, I'll spare you the
| extra comment ;)
| surement wrote:
| the average tenure for software engineers at most companies
| is two years, so yes
|
| it's not just onboarding, a newer/more junior engineer is
| much more likely to misunderstand something and introduce a
| bug if specific context is required to understand the code
| tabreu wrote:
| This. Balance is key imo.
| jxf wrote:
| > I don't want to be the one to advocate for delaying features so
| we can rename broadcast-service to broadcast-and-new-
| responsibility-service. That's going to be an unpleasant
| conversation with your product manager, for good reason: Because
| this never should have happened, and it's a waste of time to
| change the name.
|
| I couldn't disagree more. This is exactly why you would want the
| name to be descriptive. If the thing that's supposed to be a
| notifications service suddenly also starts processing payroll,
| that's absolutely a friction point that should give people pause.
| [deleted]
| sesteel wrote:
| Could not agree more. Naming things for what they do encourages
| other behaviors like deprecation strategies and extension
| strategies that are non-disruptive to others. It makes people's
| lives easier if your work follows a level of rigor for naming.
| Products and companies can do many things under a single name,
| APIs should try to do the fewest number of things under a given
| name while fitting the concept as closely as possible.
| bmitc wrote:
| I could not disagree more.
|
| > Trouble is, names are hard to change.
|
| No they're not. People just aren't determined or organized.
|
| > It's impossible to predict with certainty how your software's
| requirements will evolve over time.
|
| You don't need to predict it. You evolve things as needed,
| including names of components of the system.
|
| The idea that you need to pick a generic name because you don't
| want to specify exactly what a service does and instead want to
| change responsibility constantly without change its name is
| weird.
|
| > And then the cherry on top, the final nail in the coffin of
| descriptive names: They're just too hard to say and remember, and
| they're no fun.
|
| Why are software engineers like this? My idea of fun is not
| simply calling things Magneto and Cyclops, or Potter or
| Dumbledore, or Denali and Everest, or Wham and Bam, or whatever
| else. You know what is fun when it comes to work? Things that
| work, are named appropriately, are understandable, and people not
| needing trivialities. The amount of stress coming from things
| going in the opposite direction makes people's lives much less
| fun.
|
| I know software engineers like to blame management for all their
| problems, but I have come to the general conclusion that software
| engineers cause their own problems.
|
| I've worked at companies that name things like this (sadly, it's
| most companies), and you can work there for months before you
| know what <cutesy name> does. It's because it's generic _and_
| because a "fun" name was chosen, its responsibilities have not
| only changed but its number of responsibilities have changed. By
| not needing to change the name because it's not descriptive, it
| naturally starts to become a catch all monolith because one has
| removed all friction to not doing so. You end up with the
| situation of not being able to say "Startrooper does <x>"
| because it doesn't just do <x>. It does a million other things
| because "Startrooper is where we put things because we don't want
| to create a new component or service".
| civilized wrote:
| > You end up with the situation of not being able to say
| "Startrooper does <x>" because it doesn't just do <x>.
|
| And this leads to all the dysfunctions software engineers are
| supposed to care about protecting against. If a system has no
| high-level invariants, it is an organically evolved hairball
| that only a small number of Gurus, typically the people who
| oversaw the entire multi-year evolution of the hairball,
| understand or care to understand. This sets you up perfectly
| for endless Lava Anti-Pattern hell: only a Guru can change the
| system. For everyone else, the system can never be changed,
| only added to.
|
| That said, point taken from the other comments saying how names
| can be hard to change due to external constraints. Maybe the
| name matters less than the discipline to make sure that
| "Startrooper does X and only X". Internal documentation should
| attempt to thoughtfully name or concisely describe the
| functionality of something, and if it's not possible to do so,
| that suggests that the system does not follow modularity best
| practices.
| ImPleadThe5th wrote:
| I think there is a happy medium. I think you can have a cutsey
| name that gently suggests what the service is responsible for.
|
| I don't fully know what _task-service_ does, I don 't know how
| it differs from _scheduled-task-service-v2_. In the same way I
| don 't know what _starship_ does or how its different from
| _rocketship_.
|
| But I can probably guess and easily remember what 'automated-
| task-scheduler' or 'The Taskinator' does.
|
| I don't think it has to be an all-or-none thing. A well thought
| out cutsey name can be just as effective as a well thought out
| descriptive name. The issue is when the names are picked lazily
| or at random IMO.
| bmitc wrote:
| I agree with there's a middle ground, especially depending on
| what level you are in the stack. However, I would consider
| those examples you gave to be descriptive and certainly not
| overly cutesy or fun.
| causi wrote:
| Modern generic-ass naming schemes are absolutely infuriating. I
| hear someone say "oh yeah, it's been easier since we moved our
| Blue processes into Laundr containers which we manage through a
| mix of Bicycle and Parakeet" and my lungs are not big enough
| for the sigh I want to emit.
| Spivak wrote:
| Well yeah because those things are all _specific
| implementations_ of services. They need to have unique names
| for preciseness.
|
| "Oh yeah we've moved our app processes into containers which
| we manage with our workload scheduler and discovery service."
|
| What is the app? What kind of containers? What kind of
| scheduler? What kind of discovery service? Guess you just
| have to know. Verses.
|
| "Oh yeah we moved our frontend Rails processes into Docker
| containers which we manage with Nomad and Consul."
| lo_zamoyski wrote:
| Try discussing Elastic Beanstalk around non-dev coworkers.
|
| Labels can obscure and obfuscate as much as they can reveal.
| One must ask _what_ the badly named thing _is_. What does it
| _do_?
| taneq wrote:
| And then you look up the Blue website and it just says
| "revolutionize your business by streamlining Laundr
| workflow!" and the Laundr website describes it as "flexible
| double-acting hypercraft for Parakeet ecosystems" and the
| Bicycle website just says "Bicycle" with a giant picture of a
| fixed-speed bike.
|
| (I'm assuming you made all these names up but honestly I
| can't even tell any more.)
| marcosdumay wrote:
| They all have a "know more" session with a video (it
| doesn't tell anything more), a huge set of companies that
| use them, and a link to the documentation, where you can
| find a diagram with arrows pointing all over Laundr, Blue,
| Bicycle and Parakeet.
|
| If you insist on the docs, there are installation
| instructions (use Docker) and something that looks like an
| API. But it's not clear even if you must use the API to
| interact with the thing, or if it's the development docs.
|
| Is there some kind of consultancy doing those sites?
| Scubabear68 wrote:
| I agree with you. The cutesy names also derail a lot of
| conversations if you try to explain key points of your
| architecture to non-technical users (eg doing a high level RCA
| after a major outage with management).
| superb-owl wrote:
| > Trouble is, names are hard to change.
|
| > No they're not. People just aren't determined or organized.
|
| This is very untrue.
|
| Many moons ago my company changed its name, and we _still_ have
| the old name lingering around in stupid places. There are e.g.
| several third-party services which simply won 't let us change
| the name and carry our data forward, or where proper migration
| would take eng-months.
|
| I guess you could say we're "not determined enough" (pause
| development! take the data loss!) but it just doesn't make
| business sense to pursue it.
| bmitc wrote:
| We're talking about software service and component names. Not
| names in general or company names.
| lodovic wrote:
| In a large enough project, this sometimes results in pull
| requests covering hundreds of files. While the renaming
| itself may be a simple task, getting multiple reviews takes
| a lot of effort and management may have other priorities.
| bmitc wrote:
| I have renamed a large-ish service that was integral to
| the whole system before. For one, it wasn't that hard.
| And secondly, it usually reveals some existing issues and
| architectural deficiencies.
| Spivak wrote:
| By doing this your names aren't in 1NF and you're making
| it harder than needed to do updates. If your names are
| cute/unique then changing, expanding, or reducing service
| responsibilities just means updating the single document
| that says what Dreki does.
| ddulaney wrote:
| Software names and component names can be really hard to
| change though, especially because those names tend to leak
| into the public API.
|
| When my company got acquired, they rebranded our C++
| library, but to this day the old software name persists in
| the namespace it uses because they weren't willing to break
| every customer's code. The name of the software can become
| part of the API in lots of ways (URL component, C++ or Java
| or other namespace, executable file name for scripting,
| etc.).
|
| So yes, software service and component names are hard to
| change when customers start relying on them.
| bmitc wrote:
| So why not rename versions to cutesy names then? Function
| names? Argument names? That way, you never have to rename
| anything and can just change the behavior.
| superb-owl wrote:
| It's the same principle IMO.
|
| The name gets repeated in _so many places_ if it 's
| important. Documentation, code, URLs, databases--even just
| _finding_ all the places you need to change it involves a
| ton of work.
| surement wrote:
| > The name gets repeated in so many places if it's
| important.
|
| like the parent points out, the named thing is likely
| "important" precisely because it had a non-descriptive
| name to begin with and engineers added things to it they
| shouldn't have
|
| if it had a descriptive name then other functionality
| would've been put in their own module
| bmitc wrote:
| See my other comment in another reply, but are you
| suggesting that it's better for something to keep the
| same name while also changing its behavior and purpose?
| It doesn't make any sense.
| yokoprime wrote:
| Vermeer Technologies still linger in Microsoft 365. I think
| they were acquired in the 90s and their product became
| Frontpage, which became SharePoint. A bunch of critical
| services lives in _vti_bin
| whoisthemachine wrote:
| I too have worked in code bases that have included one or two
| company name changes in them, and it can really add
| unnecessary noise to the source. So I think this is actually
| a counter-argument for using "cutesy" names - swap "cutesy"
| with "branded" names, and you may see what I mean. This is a
| basic thing I learned early on and teach others - do your
| best to not include the name of a product in your codebase,
| rather focus on the function when trying to name something.
| It will do you no good if something is called `MyCompanyCart`
| when it instead could have just been called `Cart`. Most of
| all, don't include the name of the company in the codebase,
| especially as variable names, and double especially in data
| definitions.
| williamcotton wrote:
| The problem with using a brand name in code is that the
| audience for the brand name is external to the company and
| subject to change due to conditions in the market.
|
| The problem with descriptive names arises when it becomes
| hard to distinguish between components named "AdServer,
| "AdRendererServer", "AdStorageServer".
|
| It's liking naming a WWII bomber "Fuddy Duffy" and painting
| Elmer Fudd on the side. It's a lot easier to find and talk
| about than K297400!
| pfix wrote:
| Isn't that why namespaces were invented? You put those in
| the namespace `AdServer: { Server, Renderer, Storage }`
| williamcotton wrote:
| Sure, but what if the AdRendererServer is written in
| Python and the AdServer is a Rails app? These tend to get
| turned into acronyms like ARS and AS, and then "ars" and
| "as". So a meaningless grunt or an evocative, memorable
| word?
| whoisthemachine wrote:
| Namespacing can exist in more ways than just in code.
| Surely you could have your server, renderer, and storage
| _components_ in one repository under the _Ads product_ :
| Ads/ Server Renderer Storage
| gnull wrote:
| Agreed. People may not be determined enough and that's fine
| because not every cause is worth determination.
|
| I say this each time someone wants to rename something for
| social justice reasons. Renaming is a lot of hussle, and if
| you decide to go for it you better know what exactly it is
| that you're buying with it.
| pjc50 wrote:
| There are quite a few of these. Jenkins has "Hudson" in its
| internal namespaces. Various Microsoft products have their
| old names in classes. Once a name is used externally, it
| doesn't matter how organized _you_ are, there are uses
| outwith your control.
| giraffe_lady wrote:
| NSeverything in apple APIs is another good one I think.
| whatshisface wrote:
| Now it stands for NameSpace.
| Spivak wrote:
| Another example is Discord. In the beginning Discord servers
| were called Guilds and that's still their name in all their
| documentation and APIs. So it's more than company names.
| 71bw wrote:
| Discord is a... indecent woman to work with, if you want to
| build a bot once so that it works for any longer period of
| time... you need to wake up, because that's sadly not how
| it works.
| Spivak wrote:
| I have no idea what you're talking about but Discord has
| got to be one of the most pleasant bot development
| experiences that exists. Their shit is really well
| architected and their API handles so much lifting for
| you.
|
| I get that some people were burned by the switch from
| "free-for-all text bots" to structured bots with OAuth
| but the new way is so so so much better.
| GuB-42 wrote:
| > No they're not. People just aren't determined or organized.
|
| You just provided your own counterargument. People naturally
| aren't determined or organized, that's why names are hard to
| change.
|
| You can't change human nature, you can only work around it, and
| cute names are a solution for that. Cute names work even if
| people are disorganized, and they are. Furthermore, cute name,
| rather than purely generic or descriptive names evoke emotions,
| making them more memorable, another human thing.
| threatofrain wrote:
| Really not sure this works for homebrew with their brew and
| tap and keg naming theme.
| bumby wrote:
| > _You can 't change human nature, you can only work around
| it_
|
| You can create systems that provide the guardrails and
| incentives to modify human behavior though.
|
| The root of much of this discussion is communication, which
| is a near-ubiquitous problem in relatively large
| organizations. Communication, in this instance, is that
| people want to have a clue about what something does.
|
| The authors point is that as code changes, the names may no
| longer communicate what that code does. Unfortunately, their
| suggestion to make cutesy names does nothing to fix the
| communication issue. We're still left with poor communication
| about what the thing does. It's a veiled attempted to pretend
| like they're solving the problem of communication, but it's
| just a disguise that leaves the same problem at the end of
| the day.
|
| At least with descriptive names, I can have some clue as to
| what the code _used_ to do, and maybe glean from that why it
| is the way it is now.
| discreteevent wrote:
| > You can't change human nature, you can only work around it
|
| Yes you can. When a person becomes a civil engineer they are
| trained to change their nature so that when they design a
| bridge they do it in a way that meets all the standards with
| full documentation rather than the way they would sloppily
| design their dogshed at home.
| MrGilbert wrote:
| But isn't that exactly the "work around it" part? There are
| full standards one needs to adhere to, so you basically
| work around the sloppy part of human nature.
| DoughnutHole wrote:
| Exactly - engineers don't change their nature, they're
| legally mandated to follow very strict rules regarding
| best practices. They work in heavily constrained systems
| with checks and balances to prevent slip-ups. If they
| _don 't_ follow the rules and something goes wrong
| they're legally liable.
|
| Strip away the systems that coerce engineers into
| complying with best practices and you'll very quickly see
| how little their "nature" has changed from the average
| person's.
|
| This "cute names" pattern is simply a system to prevent
| some possible bad outcomes of developers free-styling.
| Whether it's worth the tradeoffs is debatable, but feeble
| systems like this are all we've got unless we establish
| regulatory bodies like those in "real" engineering.
|
| The millions of programmers in the world aren't going to
| all magically develop discipline - software engineering
| necessarily requires building your systems with that lack
| of discipline in mind.
| bumby wrote:
| Software development seems much more opposed to
| standardization than traditional engineering disciplines.
| I don't know if it's an artifact of software development
| itself (e.g., things are just so easy to change by
| comparison that it becomes hard to set a standard because
| things move so fast) or if its an artifact of software
| being a much newer discipline than others. E.g., when you
| look at mechanical designs from the early industrial age,
| it becomes pretty clear there were no standards then
| either.
| crispyambulance wrote:
| > ...software engineers cause their own problems
|
| yep. I once inherited a bunch of C++ applications in which the
| class hierarchies were named after Lord of the Rings
| characters. FML!
| gloosx wrote:
| I feel you here, amount of non-descriptive stuff inside cold
| imperative spaghetti is now really impressive across companies,
| I can't really call something like this a system but a nailed
| coffin for the business. Only with solid experience comes the
| knowledge that you need to express you mind-train as simple as
| possible to understand from first glance and your migraines
| will go away
| Pietertje wrote:
| I could not agree more... with you. On top of that, good luck
| onboarding new recruits or people that move departments....
| Cute names are just like abbreviations, they are jargon and are
| an unnecessary hurdle to become effective.
| perrygeo wrote:
| > you can work there for months before you know what <cutesy
| name> does. It's because it's generic and because a "fun" name
| was chosen, its responsibilities have not only changed but its
| number of responsibilities have changed
|
| Excellent insight! If you use cutesy names, the intent of the
| component will get muddled and responsibilities will be strewn
| about. I've never seen an exception. Your components become a
| fuzzy set of containers into which all ideas are tossed without
| any design intent.
|
| The only way I've seen to avoid this is to develop your own
| taxonomy/dictionary defining what all the cutesy names mean,
| what their interfaces/boundaries should be, etc. At that point,
| consider how much time you've wasted building and training your
| team on a bespoke vocabulary ... why not just encode the
| meaning into the name itself? Precise naming leads to better
| design and most importantly, encourages future developers to
| actually following that design.
| starkd wrote:
| It seems these cutesy type names are more representations of
| proprietary code than open source modules. The name becomes
| opaque to its internals.
|
| I noticed when I switched form MS Windows to Linux, there was
| a marked difference in the names of tools and modules. So,
| you could get a better high-level understanding for how it
| works. With Windows, the solution was more than likely
| strictly prescriptive. But with an open source design, it
| becomes much easier to grok the whole setup. Not sure if this
| is entirely do to naming conventions. It might also have to
| do with the online communities.
| michaelmior wrote:
| > > Trouble is, names are hard to change.
|
| > No they're not. People just aren't determined or organized.
|
| I think this point from the article gets to the harder part.
|
| > Once you've said a name, it starts to stick in people's
| heads, and it slips beyond your control. Other people use the
| name in conversation and it ripples out through the
| organization.
|
| Technical modifications to change a name are one thing. Once
| people are stuck with using a particular name, it can be hard
| to change that.
| tialaramex wrote:
| Right, there are cases at work where users are like "Foo
| doesn't work" and you have no idea what Foo is, and turns out
| the users _call_ it Foo because that was the name of an in-
| house service 15 years ago which did roughly the same thing,
| then we switched to Cloud Bar, and actually a few years ago
| Cloud Bar went on Our Incredible Journey
| https://ourincrediblejourney.tumblr.com/ so we built a _new_
| in-house service Baz, which mimics most of what Cloud Bar
| did, yet the users still call it Foo even if they weren 't
| here 15 years ago, that's what the person who taught them
| called it. You need to investigate a problem in Baz, even
| though the user said Foo, if you like you can tell them it's
| Baz as well, but like when teenagers correct their parents
| about teen slang it's not likely to have much real effect.
|
| And you might say, "Descriptive names would fix that". No
| they wouldn't. The user thinks Foo is a Wibbler Manager, if
| you called it "Wibbler Manager" they'd agree that's
| descriptive - but actually managing wibblers is trivial, its
| main purpose is to stop them from _mis-managing_ the wibblers
| by providing detailed Doop-de-doop so they stop messing about
| with the wibblers when they 're perfectly fine. Which means
| the Cloud product it got replaced by isn't really "managing
| wibblers" at all, it's a Doop-de-doop viewer. Except whoops,
| nobody makes a cloud Doop-de-doop viewer, so it's actually a
| Thingy viewer, and there's a shim turning Doop-de-doop into
| Thingy. When this gets in-housed again, chances are the in-
| house replacement still just handles Thingy. So in terms of
| _description_ the user thinks their problem is with the
| Wibbler Manager, but it 's actually the Thingy Viewer...
| we're no better off, you still need somebody to tell you what
| the hell the users are talking about.
|
| Names are what people call things, it is _rude_ to call
| people by a name they don 't like. But inanimate objects
| don't have feelings, so you should just call them whatever
| you want. Emperor Norton Bridge is a better name than "Bay
| Bridge".
| hgomersall wrote:
| It's worse than that - the name is a brand so develops value
| in its own right. It's not just hard to change the name in
| peoples' minds, it's downright damaging (unless your product
| was crap, in which case changing the name might be a good
| strategy).
| grahar64 wrote:
| Names are super hard to change. They end up everywhere, service
| directories, URLS, DNS, infrastructure, package names...
|
| It might take a months of work to change a name, just to fix
| the name of a service which is no longer accurate.
|
| Instead most companies will say something like "that is the
| translation-service, it is 10 years old. It doesn't translate
| anything anymore, but provides load balancing and Auth"
| afarrell wrote:
| Cute names are fun for the people creating them and writing
| code. They are stressful for the people trying to make sense of
| code and maintain a product under a deadline. The question is,
| which matters more:
|
| A. Having fun yourself over the course of a week.
|
| B. Getting a job done and helping your coworkers get their job
| done over the course of years.
| surement wrote:
| So many software "engineers" think their job is to make
| writing their code easier rather than to make reading it
| easier by the rest of the company. Presumably they think that
| the faster they write code, the better they are as engineers,
| and then they add "fighting fires" type skills to their
| repertoire for all the bugs they contribute to by making code
| opaque to everyone else.
|
| Prevent fires, take time writing good code, your (current and
| future) coworkers and customers will thank you.
| xeyownt wrote:
| I guess the point is to give cute names to things that will
| last years and have a large scope, not to every variable in
| your code.
| afarrell wrote:
| This calls for a marketing person with more experience in
| branding. I'd aim for meaningful metaphors.
| BlueTemplar wrote:
| And if we're talking years, B probably involves yourself too
| as you are likely to forget what the least memorable even
| "cute" names are associated with.
| pmelendez wrote:
| > You know what is fun when it comes to work? Things that work,
| are named appropriately, are understandable, and people not
| needing trivialities
|
| I don't know I agree with this. Microsoft has taken the
| descriptive naming style all the way down to products. Not only
| names like Batch or Functions don't add much value, but also it
| makes searching information about them much harder than "cute"
| names (such as Excel).
|
| I also think we tend to overthink this too much. In the end,
| the significance of names is as high as choosing between tabs
| or spaces.
| formerly_proven wrote:
| This really seems to have started at Apple and has been
| copied by both Microsoft and Gnome. I don't have any UX
| expectations for MS [1], but in Gnome it's irritating because
| most Gnome applications don't display their real name
| anywhere in the UI any more, so you have to Google what the
| binary and package names are etc.
|
| [1] I tried to open calculator on a Windows 10 box and it
| doesn't work any more, even launching calc.exe directly just
| gives a weird error message that "I need a new app for
| opening this ms-calculator:// link". Wat.
| cfuendev wrote:
| > Microsoft has taken the descriptive naming style all the
| way down to products
|
| May be more on the "Developer Products" side, but this is
| exactly how I feel about PowerShell cmdlets... Did
| PowerShell's developer team dislike Linux's
| software/package/scripting ecosystem so much that they had to
| make two-word long capitalized command names a good practice?
| surement wrote:
| > Not only names like Batch or Functions don't add much value
|
| overly vague names have the same problems cute names have,
| and you generally see the same type of people using them
| (those who think software is "hard to change"-you're thinking
| of hardware!)
|
| countless codebases have something called "entity" some
| geezer wrote a million years ago that the only reason it
| hasn't been deleted is that it's so generic everything
| depends on it
|
| code that's hard to change or delete is bad code
| andrelaszlo wrote:
| Haha, I am not picking sides but I recently saw a suggestion
| to move a service's DNS records from Cloud DNS to Cloud DNS.
| One was GCP and the other some smaller provider.
|
| For the big cloud providers, I've definitely seen people
| struggle with the names. Is it Google Compute Engine or
| Google Cloud Engine? Which one is which of Google Cloud Run
| and Google Compute Engine? Amazon Route 53? Route 57? 35?
|
| I guess the bigger the service the more creative name it
| should have?
| fragmede wrote:
| DNS runs on port 53, so it's easy to remember the name of
| AWS' DNS service.
| gilbetron wrote:
| I utterly disagree with you. After 30+ years of doing this, I
| almost always despise "descriptive names" - they are almost
| always wrong, generic, and hard to say/type. They are difficult
| to change, and even if you do change them, you just end up with
| another crappy descriptive name. "database-writer" or "user-
| database-writer" or "database-post-writer" or "event-logger" or
| "event-logger-2". While every once in a while you'll encounter
| a descriptive name that lets you actually know what it does and
| doesn't change over time, the vast majority of the time that
| name is still hard to write/say and so people use initials
| which makes the descriptive name pointless.
|
| Use a non-descriptive name, because you can't tell what a
| service/app does by just the name. People say "google" not
| "global-web-searcher". You can't tell what a service really
| does by just the name, so stop trying.
| JoBrad wrote:
| Exactly. Being descriptive is how you get a service that does
| something completely unrelated to its name, later on. Or
| worse, you end up with 2 services with similar names that do
| similar things, and users aren't sure why there are 2, but
| just know which one they like.
| seti0Cha wrote:
| I too have been doing this for decades and I completely
| disagree with you. The vast majority of names I see are
| mostly correct, with the exceptions representing the areas
| with most technical debt. It is far easier to remember the
| handful of services with bad names do than to have to
| remember the mappings for every piece of functionality. If
| there's an order service, it's pretty good bet it will
| process orders. If there's a search service, it probably does
| something with search. Does it also do billing? Maybe. Then
| that's one I'll just have to remember. But it's way easier to
| remember "some bonehead put billing in the orders service"
| than "orders and billings is snowwhite, search is sneezy...or
| was that dopey?" And if you have an orders service that
| doesn't do orders...well, there's clearly some very bad
| technical debt in that area. That's worth knowing too.
| bmitc wrote:
| Descriptive names can still be bad. Cute names have no chance
| of being useful. Someone else pointed it out or alluded to
| it, but I suppose there is a gradient of abstraction. The
| level of abstraction, from product to service to component to
| module to function to variable names, probably determines
| some allowance in how generic the name can be, from more
| generic to less generic, respectively.
| evandale wrote:
| > Cute names have no chance of being useful
|
| Are the names Amazon, Google, Facebook, Kleenex, Q-Tip,
| Thermos, Yo-Yo, or Zipper useful? They're all cute names
| and I'm positive most people could tell you what each of
| these things do. How is that not useful?
| bmitc wrote:
| See https://news.ycombinator.com/item?id=34324480
| ycombobreaker wrote:
| > Cute names have no chance of being useful.
|
| A cute name can be useful if it implies its intent. This
| usually relies upon some social shared context.
|
| Gopher: mechanism for fetching data
|
| Ask Jeeves: search engine
|
| Alta Vista: i guess literally a lookout point
|
| Web itself is an analogy, and probably so successful that
| it no longer sounds cute.
| [deleted]
| dogleash wrote:
| > Why are software engineers like this?
|
| They're not. Some are.
|
| Others are dead set on no cutey names. Causing people in their
| vicinity go around asking "why are software engineers such
| sticks in the mud?"
|
| They're not. Some are.
| mattlondon wrote:
| No no no no no. Please never ever do this.
|
| From experience, this is thew worst possible decision to make in
| anything apart from the smallest of organisations (i.e. where
| production is small enough that all the engineers _know_ (like,
| _really know_ inside-out and have it all in their head - not just
| "aware of")), at which point you don't have much to worry about
| when it comes to renaming something.
|
| Please, put yourself in the shoes of someone else. Someone who
| doesn't know what "PonySparkles" or "B-52" or "Starling" or
| "Hydrogen" or "Pokemon" or "PapaSmurf" or "ProjectSmart" or
| "Dylan" or "Everest" or "Kathmandu" are, or doesn't get the
| "joke" about why this thing is called "TinkerBell" and not
| "BroadcastService".
|
| The original owners/authors will inevitably leave the company,
| and new-starters won't know what the names are unless someone
| tells them (and even then I can promise you they'll be thinking
| "why did you call it that?"). Discoverability will also be poor,
| so someone else in the company will probably end up duplicating
| your effort because no one realised that we already had
| BroadcastService, or struggle to understand why they cannot get
| <some simple thing working> because it is impossible to
| understand what needs to happen without knowing the Secret
| Gatekeeping Knowledge of the magic Cute Names they need to know
| about.
|
| Just look at AWS service names as an example - what the hell does
| BottleRocket or Textract or Polly or Route 53 mean? You have to
| go read docs to find out what those Amazon services actually
| _do_.
|
| Just please don't do it. Please use simple general words that are
| descriptive and as obvious as possible.
| vvillena wrote:
| As per the article: The problem is that descriptive names don't
| stay that way. Descriptive names turn into misleading names as
| the things they refer to change over time. And while code can
| be refactored, it's very hard to refactor a service name, and
| almost impossible to refactor it away from people's minds.
| heavenlyblue wrote:
| Cute names are basically the equivalent of calling everything
| in your code "variable_1", "project_2". Descriptive names may
| be misleading, but at least they attempt to capture the
| intention rather than completely disregard it.
| MayeulC wrote:
| Well, if you change the role of a named thing, change the
| name too. The role change is probably breaking many
| assumptions already.
|
| You can also keep the old name around as a stub to talk to
| the new one, if needed (like during a transition period where
| it becomes deprecated).
___________________________________________________________________
(page generated 2023-01-10 23:02 UTC)