Live data from Hacker News

Software component names should be whimsical and cryptic

medium.com

241–250 of 339 posts

Re: Software component names should be whimsical and cryptic

#241

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

This is what I'm getting at though. If you work inside a MANGA company or something, then I imagine your life is probably dominated by navigating a huge byzantine ecosystem of services with uptime demands and tons of legacy code. Presumably there's lots of $$ riding on evolving those systems incrementally. In this frothing, roiling context where the only constant is change, I can see how it will often make sense to e…

>MANGA company

I'm gonna close the Internet for today because you, sir, just won it

Re: Software component names should be whimsical and cryptic

#242

> Names should make you smile. Yes, you, specifically. You should get a dopamine hit whenever something you created comes up, even when it’s in a sentence like “Shelob has broken again.” Fun is one of the most important things there is. I'll never understand this mentality, where a silly project name is a source of "fun." I would never dare tell anyone what should be fun for them... except in this case, where I will…

> I'll never understand this mentality, where a silly project name is a source of "fun." I would never dare tell anyone else what should be fun for them... except in this case, where I will say that funny names are not actually fun.

I worked in a company that would "break ground" a new microservice every other week with overlapping scope of other microservices. (poor planning in resource allocation), which lead to some services named after Greek mythology that loose describes what service does...sometimes... Then they started giving more descriptive names, services that just do X and named X, except later they started doing Y, and now it's confusing.

Then we had service XYZ (abbreviated from what it supposed to do), it took too long to build, so naturally management decided to make a Z service and remove functionality from XYZ.

I think the author comes from a similar place where scope for service is constantly changing, and silly names are the only source of dopamine.

Re: Software component names should be whimsical and cryptic

#243

Earlier quoted context omitted.

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.

Do products/components really evolve so much that the name frequently become outdated? Half the article is like, " There was a component called YamlParser, which is now a browser-based stable-diffusion renderer! "

Yep, enough that they need a caveat every time someone new is told of the product. It happens, and it's gotten worse due to Agile.

Re: Software component names should be whimsical and cryptic

#244

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…

The tone of your post is unnecessary and not helpful to your point. I don't agree with the authors point but I can say that without being insulting or snarky. In spite of that, when did "making a database product" count as not "hard?" Building a database isn't "real software engineering™?" Since when was building "authorization microservices" easy? In the simplest case, sure. But authorization in general is a huge pr…

On the contrary, I assume making decentralized database products is very hard. And I don't doubt that authorization is a whole can of worms. My point is not that they're easy, but that they're the type of problems you are most likely to care about if you're building a web service.

A web service. Not a moon rocket, or an MRI machine, or high frequency trading software, or computation fluid dynamics simulations, or a compiler, or a video processing pipeline, or a word processor, or a 3D game engine.

So, just saying: When bloggers consider the headline "Software component names should be whimsical", I wish they'd spend a second to ask themselves whether their advice actually applies to any of the niche domains I mentioned, or if it's just a best practice for their fellow web service developers. Presently, there's a cultural trend that you don't have to bother with that step, and you can just write as if your audience is always the other web service people in the valley. To me, that gets very grating, and that's where the snark comes from.

Re: Software component names should be whimsical and cryptic

#245
post #239

> Names should make you smile. Yes, you, specifically. You should get a dopamine hit whenever something you created comes up, even when it’s in a sentence like “Shelob has broken again.” Fun is one of the most important things there is. I'll never understand this mentality, where a silly project name is a source of "fun." I would never dare tell anyone what should be fun for them... except in this case, where I will…

I know this doesn't really advance the discussion that much, but... if you haven't seen this Krazam video, it's a sketch about that exact sentence there: https://www.youtube.com/watch?v=y8OnoxKotPQ I'm completely with you that name choice is not necessarily where something needs to be fun, and most people don't realize that once you name something, it's probably around for 5-10 years whether you like it or not. Or if…

[deleted]

Re: Software component names should be whimsical and cryptic

#246
post #242

> Names should make you smile. Yes, you, specifically. You should get a dopamine hit whenever something you created comes up, even when it’s in a sentence like “Shelob has broken again.” Fun is one of the most important things there is. I'll never understand this mentality, where a silly project name is a source of "fun." I would never dare tell anyone what should be fun for them... except in this case, where I will…

> I'll never understand this mentality, where a silly project name is a source of "fun." I would never dare tell anyone else what should be fun for them... except in this case, where I will say that funny names are not actually fun. I worked in a company that would "break ground" a new microservice every other week with overlapping scope of other microservices. (poor planning in resource allocation), which lead to so…

>I think the author comes from a similar place where scope for service is constantly changing, and silly names are the only source of dopamine.

Upon the recognition of this is the time you should have your resume updated and you start responding to some of those LinkedIn reps that have been emailing you.

Re: Software component names should be whimsical and cryptic

#247
post #76

Earlier quoted context omitted.

Both of which cower in fear when vi strolls by.

All fear the mighty `w`, `X`, and, most terrifying of all due to the uncertainty of their proper pronunciation, `[`!

But even he respects the one true troll :!

Re: Software component names should be whimsical and cryptic

#249
What I take from this that across languages, we ought perhaps to have the option, now and then, to use names have two parts: blotwort.django_lint for example. The whimsical part is permanent, the descriptive part is ignored when compiled (has no semantic force) and can be changed as needed without altering how the program executes.

Re: Software component names should be whimsical and cryptic

#250
post #7

If you went down the hell hole of microservices please do give descriptive names to services.

I think the point still somewhat stands. Imagine a “UserProfile” service. It’s accessed from everywhere to show the handle name, address, icon etc. of your user. Your application grows and your users want way more customization, now they get personas and avatars and can show different profile to different people. Those are full of breaking changes that you want to isolate from the legacy “UserProfile”, how do you nam…

Tell me you don't version your APIs without telling me you don't version your APIs.
Post reply on HN