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

Names should be cute, not descriptive

ntietz.com

Post reply on HN
Print view View original

421–430 of 498 posts

Re: Names should be cute, not descriptive

#421

Post by throw__away7391 »

jakelazaroff wrote: post #394
throw__away7391 wrote: post #388

Earlier quoted context omitted.

It sounds like your deployment and provisioning infrastructure is sub-par. Why would you shove unrelated functionality into the same service? Especially to the point where you can't even choose a descriptive name for said service.

> It sounds like your deployment and provisioning infrastructure is sub-par. If you want to add supporting details to that — like, any at all — then we can have a discussion. The rest of your comment doesn't actually relate to anything I said.

If you need to choose a random name up front because you can't predict what the service might be doing someday, possibly you have a poor architecture--services should follow scaling and data boundaries, both of which lock you into a specific (namable) scope, or if we are more charitable to you and blame devops instead it takes too much effort to deploy new services, there too many manual steps involved, or you're doing things like hard-coding configuration or references between services, leaving you to shove unrelated functionality into the same services out of expediency.

You could make the exact arguments you're making about classes or modules. You say these are easy to change, but when your infrastructure is set up correctly services are also easy to change, it is all just code. If your infrastructure is not set up to allow services to be changed easily or I think you should stick to a monolithic architecture, because trying to do development in an infrastructure-constrained environment is a nightmare.

I have to admit initially it didn't cross my mind that this could just be bad service design, Service boundaries chosen poorly not because infrastructure makes changes difficult but because developers just didn't know or plan properly, but now that I think about it that is probably the more common case and in fact is another good argument for descriptive names--e.g. hopefully it would give one pause if they decided to add some order processing code into a service named "delivery notification".

Re: Names should be cute, not descriptive

#422

Post by zffr »

jakelazaroff wrote: post #382
throw__away7391 wrote: post #374

If you're going to do this, why not also do it for classes, function, and variables? The the reasons you wouldn't do that are also reasons you shouldn't do it for services. A product might have a code and/or marketing name, but that's a different story. You shouldn't give cute names to services or other internal components pieces of products. Every time this comes up I remember that KRAZAM Microservices video, "becau…

> If you're going to do this, why not also do it for classes, function, and variables? Because those are easy to change. Service names inevitably get strewn across who knows how many other services and pieces of infrastructure.

Are they easy to change? Consider the scenario of a SDK provided to external developers (ex: UIKit). Any symbols made to be public API cannot be changed between releases cannot be changed without breaking clients.

It's true the SDK authors can deprecate and remove symbols, but this is not always easy to do, and sometimes can take several months or years to do.

Re: Names should be cute, not descriptive

#424

Post by sirsinsalot »

ghostpepper wrote: post #353
leeches wrote: post #177

Earlier quoted context omitted.

Solved with company name or product name prefixes, like “discord-routing-service”

except nobody at discord would ever call it "discord routing service" in a conversation with other discord employees

Handily, DRS and other D-prefix acronyms are easy to spot, hear, use and map to useful names.

Re: Names should be cute, not descriptive

#425

Post by ubercow13 »

throw__away7391 wrote: post #421
jakelazaroff wrote: post #394

Earlier quoted context omitted.

> It sounds like your deployment and provisioning infrastructure is sub-par. If you want to add supporting details to that — like, any at all — then we can have a discussion. The rest of your comment doesn't actually relate to anything I said.

If you need to choose a random name up front because you can't predict what the service might be doing someday, possibly you have a poor architecture--services should follow scaling and data boundaries, both of which lock you into a specific (namable) scope, or if we are more charitable to you and blame devops instead it takes too much effort to deploy new services, there too many manual steps involved, or you're doi…

It's not always possible to know upfront the perfect architecture of your whole system. Not every business domain is as trivial as 'delivery notification'.

Re: Names should be cute, not descriptive

#427

Post by bsima »

> Your friend Sam is still Sam, even if Sam gets new responsibilities and sheds old ones.

Does Sam's last name happen to be Smith or Cooper or any of the other thousand of occupational surnames people use? Just curious..

Re: Names should be cute, not descriptive

#428

Post by imwillofficial »

I worked on a service called the Bill Auditor Service. When people wanted to find out who, wait for it, audited the bills, they knew where to go.

And sure we had some services where their name no longer reflected their purpose.

Those were refactored and renamed when the time was right.

Re: Names should be cute, not descriptive

#429

Post by jxramos »

throw__away7391 wrote: post #374

If you're going to do this, why not also do it for classes, function, and variables? The the reasons you wouldn't do that are also reasons you shouldn't do it for services. A product might have a code and/or marketing name, but that's a different story. You shouldn't give cute names to services or other internal components pieces of products. Every time this comes up I remember that KRAZAM Microservices video, "becau…

so true, names in different contexts have different needs. For internal stuff comprehension is king. I see this show up in front end and backend stuff frequently, especially in the microcosm of a console app in python where argparser can specify the `dest`, or internal name of a command line option. All my bool options get dest=is_xxx prefixes. Using more verbose names under dest is good too.

Re: Names should be cute, not descriptive

#430

Post by pengaru »

rhacker wrote: post #329

While I don't agree with the author AT ALL. I think products need two names: a marketing name and a code name. I was at a company that kept renaming the marketing name. And for some reason I couldn't get the programmers to stop spending weeks redoing packages: com.companyname.integrationhub to com.companyname.superconnector. I kept trying to tell people that the marketing name is going to change all the time and that…

> And for some reason I couldn't get the programmers to stop spending weeks redoing packages: com.companyname.integrationhub to com.companyname.superconnector.

I wonder how much open offices comingling sales/marketing/engineering has contributed to this kind of dysfunctional crossing the streams.

Post reply on HN