I couldn’t help but think about this video https://youtu.be/y8OnoxKotPQ while I read this.
Software component names should be whimsical and cryptic
181–190 of 339 posts
Re: Software component names should be whimsical and cryptic
#182Author used to build authorization microservices, and now works at a company making a database product. Once again, somebody who works on some web service bs assumes that that's as hard as the world gets. If all of your software components are constantly changing their scope, it indicates you are doing a bad job of producing an up-front system design. If your experience causes you to scoff at the concept of producing…
No post body was provided.
Re: Software component names should be whimsical and cryptic
#183Earlier quoted context omitted.
I abbreviated on the phone, but the respective full names are “X Enterprise Linux” and “X Web Services” which are literal description of what their thing is. “RedHat” and “Amazon” are generic, but the product names are highly specific. I mean it could’ve been “RedHat Cthulu” and “Amazon RainBox”.
I strenuously dispute that "Web Services" is "highly specific".
[deleted]
Re: Software component names should be whimsical and cryptic
#184Author used to build authorization microservices, and now works at a company making a database product. Once again, somebody who works on some web service bs assumes that that's as hard as the world gets. If all of your software components are constantly changing their scope, it indicates you are doing a bad job of producing an up-front system design. If your experience causes you to scoff at the concept of producing…
What bothers me about this comment is that it’s a roundabout ad-hominem rebuttal to the author’s argument. Reading the essay, I have no reason to believe the author has only ever worked on web services. But I would if I was angry and trying to discredit the author.
The author actually does discuss the nuance. They argue exactly your point saying that their “considered harmful” advice only applies in situations where the scope of the component is ambiguous/fluid/unknown/otherwise prone to change over time/etc. In cases where you have a mature fixed design, choose an appropriately descriptive name.
I’m glad you have only ever worked on projects that were perfectly designed up front. Sounds like the dream. For the rest of us, we engineer in reality. And I find the author’s point apropos.
Re: Software component names should be whimsical and cryptic
#185Here's my rules: if you're writing an API layer for your CustomerTransactions service then name it descriptively. If you're creating a tool to be wielded, name it creatively.
If your software is a "final product" which by definition can grow in requirements then it's best to use a creative name. So if you build a programming language, a build tool, a dependency analyzer, or any kind of software that has the shape of a tool; which the user can wield in a variety of ways. I'm glad we didn't call a hammer a NailPounder since it can do so much more.
Re: Software component names should be whimsical and cryptic
#186Earlier quoted context omitted.
In many environments you don't control the evolution of software. Unless the big boss does all the naming, then the people doing the naming can't stop other people from making AuthTokenValidator send change password emails and them eventually send marketing emails. ("Hey, this service already controls the noreply address...")
If you developed your services right. You’d have a notification service that does SMS,email,smokesignals… It’s up to principal/staff engineers to make sure that the components of the system stay lean to its purpose. They should be able to say “oh, we need to send an email when this happens? Here’s an email service we can use” that doesn’t introduce feature creep into AuthTokenValidator. I get what you’re saying but t…
[deleted]
Re: Software component names should be whimsical and cryptic
#187I agree with the author but for different reasons. Software should be fun! I love it when packages have goofy names. If I can shitpost with the language I'm going to get just a little more invested in it. And to be honest, even the 'serious' names fail at connoting respectability to begin with. Your grandpa would get annoyed just hearing the word 'containerisation' - and not just because he thinks computers are for n…
No post body was provided.
Re: Software component names should be whimsical and cryptic
#188Earlier quoted context omitted.
> you are doing a bad job of producing an up-front system design Or, it could be that you're actually innovating and requirements are changing faster than you write code. A late change in requirements is a competitive advantage. There definitely are systems where BDUF is a valid approach. But at the same time there are systems where making mistakes is the best way to learn. Emergent design is a thing.
It’s not “innovative” to double-down on mistakes.
Not necessarily, but could be.
Have you heard of brainstorming? The worst thing you could do is to ban mistakes.
Innovation is doing something that hasn't been done before. Inevitably that leads to mistakes.
Being sloppy also leads to mistakes.
Presence of mistakes doesn't tell you much. But lack of them tells a lot.
If all your experiments are successful, it doesn't mean you're a genius. It means you're experimenting too slow.
Re: Software component names should be whimsical and cryptic
#189I have doubts about the author's overall point, but something to consider is how does a name help/hinder search? A name that's overly mundane, say, "Go", becomes problematic to google (hence the need to search for "golang" or add other terms).
I feel almost like there's an analogy between choosing names for packages/projects and bird calls. Birds need to make their calls stand out in a given ecosystem. If you have a dozen projects like, say, "object-mapper," "object-db-mapper," "object-mapping", "object-mapper-thingy", "object-mapping-service", "db-object-mapper", it's hard to remember wtf was the one you need. If in such an ecosystem your project was named "Orangutan," it might stand out and be noticed. OTOH, if all projects in a given ecosystem have weird names like "murano", "swift", "glance", "hotdog", "gorilla", "zaqar", "cthulhu", "funky-chicken", "Sauron" or whatever, it may be hard to remember what they all do/mean -- yes, I'm giving you the side eye, openstack. In such a space, "cloud-disk" or something might win, IMHO.
Slightly tangentially related is the use of odd words in log messages to aid searchability. I've been grateful for misspellings in the past, so I could easily grep for some critical log message containing `transation_id` or whatnot. (Good struct logging makes this less necessary, thankfully.)
Re: Software component names should be whimsical and cryptic
#190Author used to build authorization microservices, and now works at a company making a database product. Once again, somebody who works on some web service bs assumes that that's as hard as the world gets. If all of your software components are constantly changing their scope, it indicates you are doing a bad job of producing an up-front system design. If your experience causes you to scoff at the concept of producing…
No post body was provided.