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

251–260 of 498 posts

Re: Names should be cute, not descriptive

#251

Post by Spivak »

bmitc wrote: post #226
lodovic wrote: post #201

Earlier quoted context omitted.

In a large enough project, this sometimes results in pull requests covering hundreds of files. While the renaming itself may be a simple task, getting multiple reviews takes a lot of effort and management may have other priorities.

I have renamed a large-ish service that was integral to the whole system before. For one, it wasn't that hard. And secondly, it usually reveals some existing issues and architectural deficiencies.

By doing this your names aren't in 1NF and you're making it harder than needed to do updates. If your names are cute/unique then changing, expanding, or reducing service responsibilities just means updating the single document that says what Dreki does.

Re: Names should be cute, not descriptive

#252

Post by DoughnutHole »

MrGilbert wrote: post #233
discreteevent wrote: post #217

Earlier quoted context omitted.

> You can't change human nature, you can only work around it Yes you can. When a person becomes a civil engineer they are trained to change their nature so that when they design a bridge they do it in a way that meets all the standards with full documentation rather than the way they would sloppily design their dogshed at home.

But isn't that exactly the "work around it" part? There are full standards one needs to adhere to, so you basically work around the sloppy part of human nature.

Exactly - engineers don't change their nature, they're legally mandated to follow very strict rules regarding best practices. They work in heavily constrained systems with checks and balances to prevent slip-ups. If they don't follow the rules and something goes wrong they're legally liable.

Strip away the systems that coerce engineers into complying with best practices and you'll very quickly see how little their "nature" has changed from the average person's.

This "cute names" pattern is simply a system to prevent some possible bad outcomes of developers free-styling. Whether it's worth the tradeoffs is debatable, but feeble systems like this are all we've got unless we establish regulatory bodies like those in "real" engineering.

The millions of programmers in the world aren't going to all magically develop discipline - software engineering necessarily requires building your systems with that lack of discipline in mind.

Re: Names should be cute, not descriptive

#253

Post by toomanyrichies »

thedorkknight wrote: post #228

So basically descriptive names might eventually become non-descriptive, or loosely connected. "Cute" names are ALWAYS non-descriptive or loosely connected though. So at worst, a descriptive name eventually becomes as bad as a cutesy name. Given my experience being onboarded onto legacy code, and bringing others up to speed on my team's code, I'd much rather have names help coders understand the systems 9/10 times as…

> descriptive names might eventually become non-descriptive

It's worse than being non-descriptive- it's that they become misleading. "Cute" names don't tell you anything. Formerly descriptive names tell you the wrong thing.

This, in turn, means developers can no longer trust that a descriptive name is accurate. It plants a seed of doubt in a developer's mind about other names. It tells them that, here at WidgetCorp R&D, just because something is named DescriptiveThingThatDoesXYZ, doesn't mean it actually does XYZ.

So now they have to verify what a given class or method does every time. Which means you have the same problem that cutesy names cause (the non-trivial effort of looking stuff up) plus the lack of trust that is now engendered in your engineering org.

To be clear, I think I still fall more towards the "use descriptive names" camp. As another commenter has said, by making it easier to add responsibilities to a certain class or service, the "use cute names" camp promotes the creation of God objects that take on too many responsibilities. But man I hate it when a class's name is actively misleading.

Re: Names should be cute, not descriptive

#254

Post by ImPleadThe5th »

bmitc wrote: post #128

I could not disagree more. > Trouble is, names are hard to change. No they’re not. People just aren’t determined or organized. > It's impossible to predict with certainty how your software's requirements will evolve over time. You don’t need to predict it. You evolve things as needed, including names of components of the system. The idea that you need to pick a generic name because you don’t want to specify exactly w…

I think there is a happy medium. I think you can have a cutsey name that gently suggests what the service is responsible for.

I don't fully know what task-service does, I don't know how it differs from scheduled-task-service-v2. In the same way I don't know what starship does or how its different from rocketship.

But I can probably guess and easily remember what 'automated-task-scheduler' or 'The Taskinator' does.

I don't think it has to be an all-or-none thing. A well thought out cutsey name can be just as effective as a well thought out descriptive name. The issue is when the names are picked lazily or at random IMO.

Re: Names should be cute, not descriptive

#255

Post by hcarvalhoalves »

Nobody today would believe naming classes after greek gods or anime is a good idea, but for some reason it's okay for (micro)services.

I've worked at places that do this, I think it's a bad idea.

Not having descriptive names turns architecture discussions into bikeshedding ("I think we should create a new service named Pikachu instead of extending the scope of the Naturo service").

Re: Names should be cute, not descriptive

#256

Post by surement »

superb-owl wrote: post #207
bmitc wrote: post #191

Earlier quoted context omitted.

We're talking about software service and component names. Not names in general or company names.

It's the same principle IMO. The name gets repeated in so many places if it's important. Documentation, code, URLs, databases--even just finding all the places you need to change it involves a ton of work.

> The name gets repeated in so many places if it's important.

like the parent points out, the named thing is likely "important" precisely because it had a non-descriptive name to begin with and engineers added things to it they shouldn't have

if it had a descriptive name then other functionality would've been put in their own module

Re: Names should be cute, not descriptive

#258

Post by lioeters »

whoisthemachine wrote: post #235

> It's impossible to predict with certainty how your software's requirements will evolve over time. And if you don't know what your software will need to do later, you don't know what the ideal factoring will be then, let alone now. It will almost certainly change over time. If you follow the idea of the "Single Responsibility Principal" with discipline, then you should create a new piece of software if changes to it…

..Or create a new product with a standard connector for both, an adaptor for lawn mower and another one for mulcher, using the same engine. It can be called Mulchwer - cute and descriptive! When the company inevitably invents a new adaptor, say a snow blower for clearing the sidewalk, the product can be renamed Mulchwer X, or Multi-Mulchwer Deluxe. It's now an all-purpose product with a set of adaptors for any front/backyard needs. It will also be a subscription-based business model, always needs to be connected to the Internet, and have machine learning for full self-driving.

Re: Names should be cute, not descriptive

#259

Post by m_mueller »

tauwauwau wrote: post #200

I think we are mixing two different scopes in the the discussion here. If you are naming a company or a product that will be offered to clients, name it something unique that'll appear in searches. However, if you're writing a piece of software that's not going to go outside the company, having descriptive name is the way to go. You can even name your products with generic descriptive names, if your company's name is…

IMO there is a middle ground: larger & long living services that are internal only, and you have 1-2 handful of them. At my current employer I've started with greek gods whose background is related with the service we're building. E.g. Apollo = god of truth = data warehouse; Hermes = messenger god = messaging service for reporting, etc. It's quite successful in that these names are more quickly adopted and recognized by internal business users, compared to giving it a boring functional name. It also clearly outlines that they are part of a wider concept (new tech stack = greek gods, legacy marked for decommissioning = mostly everything else they hear).

Re: Names should be cute, not descriptive

#260

Post by fein »

jnsaff2 wrote: post #66

Dude(tte) is losing an argument so they turn to HN for more arguments by writing a trollish blog post. I find naming to be one of the most bikeshady of activities. Pick something and move along. The more you think/argue about them the worse the outcome. Channel your first instinct but be ready to change it once it turns out to be wrong.

Does said argument have it's origins on here? I went to college with this guy (Assuming it's the same Nick Tietz) and thought it was satire, but I have no idea how people change over the years.

That or we're on the bleeding edge of Poe's law.

edit: It's far too early and my eyes skipped over the first sentence in the article.

Post reply on HN