Live data from Hacker News

Software component names should be whimsical and cryptic

medium.com

211–220 of 339 posts

Re: Software component names should be whimsical and cryptic

#211
post #6

This is terrible advice. Cryptic names are horrible. It's a layer of cognitive overhead that no one needs. Yes if it gets so big that it's out grown it's original purpose that's a problem. But if it's really big people know what it is because it's big. If it's not that big rename it!

I opt to compromise and use middle ground name, which both related and fun. A tool for sending mails via Mailgun? “Railgun” then, for example.

This is the right middle ground imo as well. It adds a bit of simple difference between the 15 different exporters, without being too far off. We have things like the "Tenant Saw" - extracts a tenant from a multi tenant system, or a foosystem-butler called Vlad - automating and scripting a bunch of busywork around the foosystem.

Re: Software component names should be whimsical and cryptic

#213
This is the absolute antithesis to how I operate and I disagree almost to the point of being offended.

Try working in an environment where team leads are allowed to make up whatever names they want, create as many projects/services as they want, and organize everything based on whim. You get this: https://www.youtube.com/watch?v=y8OnoxKotPQ

For me that is not a parody, it's lived experience.

> I’m probably being overdramatic there, but I hope my point is clear. “Descriptive” names don’t create transparency, they create the illusion of transparency. If you see that something has the name OrderStatusService, you will instinctively assume you know what it is and does, and you will probably be wrong.

When what a thing does changes then the name should also change. I almost want to counter this Medium post by arguing that READMEs should be works of fiction because the project they describe might change over time.

Re: Software component names should be whimsical and cryptic

#215
post #200

Earlier quoted context omitted.

Commercial software is mostly to solve real world problems. Real world problems can change very quickly and as such, software changes too. Sure constantly changing in the complete opposite direction is probably a sign of something wrong, but changes are inevitable and we can’t expect to reinvent the wheel or start a new project as you say when you can potentially reuse what you already have.

> Real world problems can change very quickly and as such, software changes too. So you keep the old product, and make a new one for solving the new problem. (You can even sell them on the same package.) The alternative will have almost all of your customers badmouthing you because they brought your product, and you pulled the functionality out of their feet.

You make a new one and what name will it get? :)

Re: Software component names should be whimsical and cryptic

#216
post #213

This is the absolute antithesis to how I operate and I disagree almost to the point of being offended. Try working in an environment where team leads are allowed to make up whatever names they want, create as many projects/services as they want, and organize everything based on whim. You get this: https://www.youtube.com/watch?v=y8OnoxKotPQ For me that is not a parody, it's lived experience. > I’m probably being over…

Did you read the full essay? The author agrees with you regarding your ideals. The essay is a concession to reality. I’ve seen wildly out of date readmes that cause more confusion than help, for sure, too.

Re: Software component names should be whimsical and cryptic

#217

Author used to build authorization microservices, and now works at a company making a database product. Once again, somebody who works on some web service bs assumes that that's as hard as the world gets. If all of your software components are constantly changing their scope, it indicates you are doing a bad job of producing an up-front system design. If your experience causes you to scoff at the concept of producing…

> speak as if the world of software is just writing web services.

So true. Web services are just a distraction from real software, which is writing compilers.

Re: Software component names should be whimsical and cryptic

#218

Author used to build authorization microservices, and now works at a company making a database product. Once again, somebody who works on some web service bs assumes that that's as hard as the world gets. If all of your software components are constantly changing their scope, it indicates you are doing a bad job of producing an up-front system design. If your experience causes you to scoff at the concept of producing…

I came here to write something similar. The article lists a few repos as examples of bad naming when the reality is, it’s examples of miss-naming. For a long long time I’ve convinced people to use literal names for things and not get creative. A BillingStatusService , as the author has cited, isn’t an example of a bad name. It’s an example of bad engineering that it does more than BillingStatus . Often times when peo…

>Often times when people get creative with names, the meaning dies with them

That's fine though. Anything you work on will inevitably develop a personality in your mind beyond what the name literally means, so what's the difference if the name is something like GAS (generic-acronym-service) or Fuel (GAS > gasoline > fuel).

A persuasive dev at my last job tried to insist on non-acronym names for every new service, and 5 years on, I can still remember every proper name, but none of the acronyms. That, to me, is sign of a good name.

Re: Software component names should be whimsical and cryptic

#219

Earlier quoted context omitted.

> Real world problems can change very quickly and as such, software changes too. So you keep the old product, and make a new one for solving the new problem. (You can even sell them on the same package.) The alternative will have almost all of your customers badmouthing you because they brought your product, and you pulled the functionality out of their feet.

You make a new one and what name will it get? :)

Well, as I said earlier, I don't care much about what camp you side here.

The one important thing is that if you decide you must solve some completely different problem, you should do it with a completely different product.

So the argument that a nondescriptive name allows you the freedom to change the product is bad. You never have the freedom to change the product.

Re: Software component names should be whimsical and cryptic

#220

OK, I guess I'll have to argue against. Please don't make component names whimsical. Your idea of whimsy and fun is potentially confusing or (worst case) offensive to others. Yes, make them unique and searchable. Yes, make them memorable and pronounceable. Yes, make them SFW. It would get tiring to have to keep explaining to new team members that our prime number generator is named "optimus" even if it was initially…

Sorry but a prime number generator called "Optimus" is an awesome idea.

I also kind of disagree that an "unpronounceable Gaelic word" is a poor choice. Seems like cultural discrimination. People all over the world write software, not just people who can pronounce English words.

Post reply on HN