Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software component names should be whimsical and cryptic

medium.com

Post reply on HN
Print view View original

161–170 of 339 posts

Re: Software component names should be whimsical and cryptic

#161

Post by mavxg »

jgauth wrote: post #130
dools wrote: post #86

I don’t think you need to go full startup when naming stuff, but you also don’t have to go full bureaucrat either. I once created a PHP framework called RocketSled because it was “the fastest thing on rails” and that gave rise to somewhat whimsical but also descriptive names on the same theme: RocketPack: package manager DataBank: caching auto loader Murphy: automated testing Each of those modules is named quite spec…

Where does Murphy come from?

Murphy's Law: Anything that can go wrong will go wrong.

Re: Software component names should be whimsical and cryptic

#162

Post by sebastos »

RcouF1uZ4gsC wrote: post #103

I think software component names should all just be UUIDs. This way no one is misled by the name. Also, there is much less chance that an offensive name gets picked (either intentional or unintentionally). There is also much less risk of collisions. In addition, you don’t waste any time trying to come up with a name.

And no pesky scope implied by the name! Now, each of the components can grow in a truly unconstrained manner, enveloping whatever random features were slightly more convenient to add there instead of in a new component. Amazing!

Re: Software component names should be whimsical and cryptic

#163

Post by hbrn »

sebastos wrote: post #157

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…

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

Re: Software component names should be whimsical and cryptic

#164

Post by tester756 »

I recommend this book, it was written by top people with decades of experience in creating runtime, OSes, base class libraries, designing APIs, naming and so on

Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (Addison-Wesley Microsoft Technology Series) 3rd Edition

Re: Software component names should be whimsical and cryptic

#166

Post by gabereiser »

sebastos wrote: post #157

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 people get creative with names, the meaning dies with them. When they leave the company so too does the reasoning behind the name.

The author conflates service bloat with bad names. Fix the bloat and the name will make sense. If you have an app called “Authorizer” and it does email, you failed. If you have a service called “InfraValidator” all it should be doing is validation. If it’s not (such as tensor flow’s infra validator) then the service/app/codebase is misleading and needs to be renamed after what it does.

I also hate to see overly descriptive names. Package/crate/bundle/module should help classify the name of the class/object/func_collection.

Names like “EnvironmentPostProcessor” (Spring Boot) is succinct enough to know exactly what it does. It processes environment vars after a stage.

Re: Software component names should be whimsical and cryptic

#167

Post by tengbretson »

brianmcc wrote: post #156

A handful of examples don't prove anything. If a Widget Lookup Service is used to lookup widgets for its entire lifespan, calling it Frodo isn't doing anyone any favours. And it's not like "oops some gadget polishing code fell into my widget lookup service": don't put inappropriate crap into your solution. Little discipline goes a long way.

Does knowing that it is called "Widget Lookup Service" actually convey enough information to you to be able to make meaningful changes to its implementation? If not, then its time to look up it up in your internal company wiki. Which name will yield search results specific to the service you are interested in, and which one will be heavily polluted by mentions of "Widget", presumably something common in your domain.

Re: Software component names should be whimsical and cryptic

#168

Post by ryandrake »

OK, I guess I'll have to argue against. Please don't make component names whimsical. Your idea of whimsy and fun is potentially confusing or (worst case) offensive to others. Yes, make them unique and searchable. Yes, make them memorable and pronounceable. Yes, make them SFW.

It would get tiring to have to keep explaining to new team members that our prime number generator is named "optimus" even if it was initially clever.

I don't look forward to convincing my boss we need to pull in "libAnimeBabe" as a dependency even if it's the best parser for a file format we need to import.

Nobody wants to find out a year after all of our marketing material is put together that our software name means "asshole" in another language.

Don't make me have to pronounce an unpronounceable Gaelic word every time I do a presentation on our software stack because you're Irish and just had to name your component that way.

There are lots of ways "whimsical" can backfire unintentionally. Save your creativity for the actual software solution.

Re: Software component names should be whimsical and cryptic

#169

Post by whatshisface »

gabereiser wrote: post #166
sebastos wrote: post #157

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…

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

Re: Software component names should be whimsical and cryptic

#170

Post by hbrn »

badhombres wrote: post #139
dzhiurgis wrote: post #136

Earlier quoted context omitted.

Better be consistently boring than ever misleading

But as products evolve, their boring names become misleading. At least with non-boring names you can re-define what they represent in your company.

Isn't it even harder to re-define names in a company? There might be 3 people involved in re-definition, but it affects 15 people.

How are we going to notify those 15? Do we even know who those 15 are? Are we going to create a weekly redefinition newsletter?

I think in most cases new meaning deserves a new name. Everything else is just hacks.

How hard is it to change a name is a actually a really good metric for a company. If a simple rename takes several days, multiple approvals, rounds of QA, and a scheduled release next quarter, then you probably need those hacks.

Post reply on HN