8 ms·

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 w

by bmitc 4y ago

I could not disagree more. > Trouble is, names are hard to change. No they’re not. People just aren’t determined or organized. > It's impossible to predict with certainty how your software's requirements will evolve over time. You don’t need to predict it. You evolve things as needed, including names of components of the system. The idea that you need to pick a generic name because you don’t want to specify exactly what a service does and instead want to change responsibility constantly without change its name is weird. > And then the cherry on top, the final nail in the coffin of descriptive names: They're just too hard to say and remember, and they're no fun. Why are software engineers like this? My idea of fun is not simply calling things Magneto and Cyclops, or Potter or Dumbledore, or Denali and Everest, or Wham and Bam, or whatever else. You know what is fun when it comes to work? Things that work, are named appropriately, are understandable, and people not needing trivialities. The amount of stress coming from things going in the opposite direction makes people’s lives much less fun. I know software engineers like to blame management for all their problems, but I have come to the general conclusion that software engineers cause their own problems. I’ve worked at companies that name things like this (sadly, it’s most companies), and you can work there for months before you know what <cutesy name> does. It’s because it’s generic and because a “fun” name was chosen, its responsibilities have not only changed but its number of responsibilities have changed. By not needing to change the name because it’s not descriptive, it naturally starts to become a catch all monolith because one has removed all friction to not doing so. You end up with the situation of not being able to say “Startrooper does <x>” because it doesn’t just do <x>. It does a million other things because “Startrooper is where we put things because we don’t want to create a new component or service”.

michaelmior 4y ago
> > Trouble is, names are hard to change. > No they’re not. People just aren’t determined or organized. I think this point from the article gets to the harder part. > Once you've said a name, it starts to stick in people's heads, and it slips beyond your control. Other people use the name in conversation and it ripples out through the organization. Technical modifications to change a name are one thing. Once people are stuck with using a particular name, it can be hard to change that.
- hgomersall 4y ago
  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).
- tialaramex 4y ago
  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/ 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".
pmelendez 4y ago
> 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.
- andrelaszlo 4y ago
  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 4y ago
    DNS runs on port 53, so it's easy to remember the name of AWS' DNS service.
- formerly_proven 4y ago
  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.
- surement 4y ago
  > 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
causi 4y ago
Modern generic-ass naming schemes are absolutely infuriating. I hear someone say "oh yeah, it's been easier since we moved our Bluē 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.
- lo_zamoyski 4y ago
  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 4y ago
  And then you look up the Bluē 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 4y ago
    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, Bluẽ, 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?
- Spivak 4y ago
  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."
afarrell 4y ago
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.
- BlueTemplar 4y ago
  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.
- xeyownt 4y ago
  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 4y ago
    This calls for a marketing person with more experience in branding. I’d aim for meaningful metaphors.
- surement 4y ago
  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.
Pietertje 4y ago
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.
gilbetron 4y ago
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.
- bmitc 4y ago
  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.
  - ycombobreaker 4y ago
    > 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.
  - evandale 4y ago
    > 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?
superb-owl 4y ago
> 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 4y ago
  We're talking about software service and component names. Not names in general or company names.
  - lodovic 4y ago
    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 4y ago
      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 4y ago
        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 4y ago
    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.
GuB-42 4y ago
> 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.
- discreteevent 4y ago
  > 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 4y ago
    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 4y ago
      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.
civilized 4y ago
> 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.
perrygeo 4y ago
> 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 4y ago
  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.
Scubabear68 4y ago
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).
crispyambulance 4y ago
> ...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!
ImPleadThe5th 4y ago
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 4y ago
  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.
dogleash 4y ago
> 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.
grahar64 4y ago
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”
deleted 4y ago
[deleted]
gloosx 4y ago
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

by bmitc 4y ago

michaelmior 4y ago

> > Trouble is, names are hard to change. > No they’re not. People just aren’t determined or organized. I think this point from the article gets to the harder part. > Once you've said a name, it starts to stick in people's heads, and it slips beyond your control. Other people use the name in conversation and it ripples out through the organization. Technical modifications to change a name are one thing. Once people are stuck with using a particular name, it can be hard to change that.

hgomersall 4y ago
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).
tialaramex 4y ago
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/ 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".

pmelendez 4y ago

> 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.

andrelaszlo 4y ago
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 4y ago
  DNS runs on port 53, so it's easy to remember the name of AWS' DNS service.
formerly_proven 4y ago
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.
surement 4y ago
> 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

causi 4y ago

Modern generic-ass naming schemes are absolutely infuriating. I hear someone say "oh yeah, it's been easier since we moved our Bluē 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.

lo_zamoyski 4y ago
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 4y ago
And then you look up the Bluē 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 4y ago
  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, Bluẽ, 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?
Spivak 4y ago
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."

afarrell 4y ago

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.

BlueTemplar 4y ago
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.
xeyownt 4y ago
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 4y ago
  This calls for a marketing person with more experience in branding. I’d aim for meaningful metaphors.
surement 4y ago
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.

Pietertje 4y ago

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.

gilbetron 4y ago

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.

bmitc 4y ago
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.
- ycombobreaker 4y ago
  > 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.
- evandale 4y ago
  > 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?

superb-owl 4y ago

> 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 4y ago
We're talking about software service and component names. Not names in general or company names.
- lodovic 4y ago
  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 4y ago
    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 4y ago
      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 4y ago
  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.

GuB-42 4y ago

> 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.

discreteevent 4y ago
> 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 4y ago
  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 4y ago
    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.

civilized 4y ago

> 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.

perrygeo 4y ago

> 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 4y ago
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.

Scubabear68 4y ago

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).

crispyambulance 4y ago

> ...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!

ImPleadThe5th 4y ago

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 4y ago
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.

dogleash 4y ago

> 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.

grahar64 4y ago

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”

deleted 4y ago

[deleted]

gloosx 4y ago

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