Hacker News Reader

Comment by Hokusai | Hacker News Reader

I love the joke. But, it is a serious problem.

One key part is that naming is important. This is always a fight I am willing to take. Acronyms, fantasy names, names of teams or legacy names that does not represent the functionality of the micro-service plague many companies.

If you will not name a method "Jimmy" or a local variable "Galactus", why developers are naming their micro-services in such a bad way?

I do not know what I find more frustrating, the bad naming per se. Or the fact that the same developers would lose their shit if they saw this:

  class Galactus {
    boolean Jimmy;

    void turnOn() {
      Jimmy = true;
    }

    void turnOff() {
     Jimmy = false;
    }
  }

Sometimes it feels that software development is more a religion that an engineering discipline. That there is rights and wrongs based in tradition instead of sound practices. That is why worse than the naming is the lack of self-introspection that let us here.

View on HN

So I'll throw out the argument that responsibilities of a service evolves as the product evolves. The fact that names like Galactus are blank slates can be a benefit so that you don't have to explain to some poor new grad:

"Well, you see, the identity service isn't actually the source of truth for identities anymore ever since the oauth service started taking that responsibility and the plan was to move all the endpoints into the other service but some other priorities came up, but that was five years ago..."

That is, if agility of architectural development is one of the goals of microservices, names that don't get out of date because they never meant anything except "name for this codebase" in the first place might have some benefit.

Does that overrule the benefit of a common lingo you can talk about without the domain knowledge of your system? Probably heavily depends on way many variables than even HN can hash out, but there's an argument to be made here for these naming conventions at least.

> One key part is that naming is important. This is always a fight I am willing to take. Acronyms, fantasy names, names of teams or legacy names that does not represent the functionality of the micro-service plague many companies.

> If you will not name a method "Jimmy" or a local variable "Galactus", why developers are naming their micro-services in such a bad way?

There was a post on the front page today about the "principle of least astonishment." It could not be more applicable than this example.

For those that missed it => https://wiki.c2.com/?PrincipleOfLeastAstonishment

This has been happening way before microservices became popular but it's gotten out of hand. Teams have nonsensical names as do their services. Outsiders coming in have a huge hill to climb to learn the domain because god knows why.

I reckon people might be copying the trend of giving nondescript names to particular software/services. Which isn't bad per se (I mean there's only so many ways you can rephrase 'webserver' before you run out of options), but if you split up your organisation and do the same thing to each subpart then it gets confusing.

We have something between 3 and 8 user profile services that you might interact with on a daily basis depending on where you sit. If they all had "good" names they'd all have roughly the same name. It's dumb for onboarding, but I have to say I see how "racoon" became a name.

PG has an essay on keeping your identity small. It high lights the fact that when there is no way to prove one answer is correct, it’s then subjective which is the “right” answer. He uses the example of politics. Good read.

Reply on news.ycombinator.com