4 ms·
This is why I'm a big fan of "name it Steve" philosophy. When we create a new service many people are inclined to call it something like "rhombus keyboard fibri
by gnulinux 3y ago
This is why I'm a big fan of "name it Steve" philosophy. When we create a new service many people are inclined to call it something like "rhombus keyboard fibriculator" or "octatonic runner". Usually it's of the form "{verb}er" or "{noun} {verb}er" or "{adj} {noun} {verb}er" or whatever. It's never accurate, and it's super confusing because chances are there is some other "{x} {y} {verb}er" with the same "verb". Not to mention it's super long.
Just name your things as things. Name it Pluto, Calvin, Steve, Jon, Ted, Ann, Mobius, Orpheus, Martha, Alex... I don't care. Maybe even Tomato, Artichoke, Celery, Broccoli, Pumpkin, Rooibus etc... It just needs to be as neutral as possible.
This is the power of mathematics really. When I say "monoid" do you have any idea what it might be? No, well that's great, because here is a very formal definition of this thing called "monoid". Old school names like "group", "category" etc are worse. Names like "Kolmogorov complexity", "P-Complete", "Galois Field", "Ultrafilter" are much better.
- mcbishop 3y agoAgreed. And might as well use one-syllable words that are pleasant to read / write (e.g. bob, tom, box, rack, sun).
- kbenson 3y agoThe next thing you know your using joe[1] to write joe[2] in joe[3]. At work we have an app called "directly", and an app called "indirectly". Ask me if I ever have to clarify by asking "you mean in an indirect way, in the app indirectly or in the app directly?" (the answer is ALL THE TIME) 1: the editor 2: a service you created 3: Joe-E the language
- gnulinux 3y agoJust use less common names like Brice or Werner or Rubin?
- InitialLastName 3y agoMy favorite thing is when names that I often have to communicate verbally for written use have ambiguous alternative spellings.
- gabrieledarrigo 3y agoNope! Things are never important... behaviour is! And please, after 20+ years of DDD at least, give Evans some credit: name your things after your business domain...!
- gnulinux 3y agoWell at the end of the day you will have to name your container, or instance, or server, or git repo, or db table etc... Conceptually I agree with you, behavior matters. But as the article details, when we communicate with humans, all we have is names, so we have to use names to communicate behavior. > And please, after 20+ years of DDD at least, give Evans some credit: name your things after your business domain...! This doesn't hold up in all companies. My company has more than 100 services (yeah yeah microservices suck yada yada, I don't make the decisions) you can't just name 150 things after your business domain, ultimately you're required to follow some kind of convention like "x {verb}er" etc.
- DeathArrow 3y ago>My company has more than 100 services (yeah yeah microservices suck yada yada, I don't make the decisions) you can't just name 150 things after your business domain We did just that because each of our microservices does one thing. So we have Authorization, Notifications, Tenant, Workflow and so on.
- DeathArrow 3y agoKingdom of nouns?
- rewmie 3y ago> This is the power of mathematics really. I don't think your comparison makes sense. The power of the "name it Steve" philosophy is the same rationale behind adopting codename for projects: it helps create a context to disambiguate discussions. As part of Steve, you work on the Steve web app and on the Steve service. The Steve service later can be refactored to peel out one of Steve's microservices listening to Steve's message broker. Later if Steve needs to consume data from Pluto, you know that Steve's service will chat with Pluto's service, and perhaps have Steve's message broker listen to some channels in Pluto's message broker, etc etc. Zero ambiguity. Moreover, monoliths have a propensity to outgrow responsibility-driven names. With a monolith you might start with a widget service, which then handles transactions, inventory, and order history. Once any of those responsibilities is peeled off to a microservice, do you still have a widget service along with a widget inventory service? Is it ok to keep calling widget service the widget service if it only handles widget order history?
- mr_mitm 3y agoIn my company we resorted to name many internal tools and libs after birds. It becomes a problem though when you want to publish open source tools or libraries. These days it becomes very hard to find a name that isn't already attached to a Github repo. Finding a name that is googlable, unique, somewhat intuitive and descriptive is a problem that does not scale at all. I'm not surprised the NSA ended up generating names for their tools. At least that's what they seem to do judging by names like Eternal Blue, Double Pulsar, Dander Spritz and the like. (https://en.wikipedia.org/wiki/The_Shadow_Brokers#Fifth_leak:_%22Lost_in_Translation%22 https://en.wikipedia.org/wiki/The_Shadow_Brokers#Fifth_leak:...)
- bjterry 3y agoIn WW2, British intelligence analysts inferred that a secret Nazi radar system used only a single beam based on its code name: Wotan (Odin), a god with one eye. For a long time, I have occasionally referenced this example, but today I learned that it was actually sheer luck. The prior radar system that used two beams was also codenamed Wotan. https://en.wikipedia.org/wiki/Battle_of_the_Beams#Y-Ger%C3%A4t https://en.wikipedia.org/wiki/Battle_of_the_Beams#Y-Ger%C3%A...
- still_grokking 3y agoWasn't Eternal Blue a reference to the Windows "blue screen" bug it was based on? I would guess there are also technical references in the other names.
- mr_mitm 3y agoTo my knowledge the NSA never commented on this, so where is this information supposed to come from?
- teddyh 3y agoSEND HAVE ISOLATED ORGANISM WISH CODING MESSAGE FROM CENTRAL CODES FOLLOWS OPENING NEW CATEGORY CODE FOR YOUR ORGANISM WILL BE ANDROMEDA CODE WILL READ OUT ANDROMEDA STRAIN END MESSAGE
- akoboldfrying 3y ago>"name it Steve" philosophy I think of these kinds of names as being like primary key fields in a database: Their main purpose is to distinguish the identities of various things, so it's better not to incorporate any functional/behavioural description into them because that way there's never a need to change the name in the future if the behaviour changes. The downside is that the names become arbitrary lumps of data that you have to become familiar with by rote use.
- still_grokking 3y agoPrimary keys in DBs should be natural keys in the first place. You use surrogate keys only to optimize things. So the whole analogy now points in the exact opposite direction as stated.
- akoboldfrying 3y agoWhat's an example of a natural key for a person, that never changes?
- xanderlewis 3y agoYou think ‘Galois field’ is better than ‘finite field’?
- aldanor 3y agoBoth are arguably better than 'potato field'
- still_grokking 3y agoBut GP is actually arguing to call all your things "potato". Imho that's the worst you could possibly do! Indeed.
- gnulinux 3y agoYes absolutely! As per my original comment neutral names are better. "Finite" has a meaning.
- xanderlewis 3y agoYes — a meaning that fits. Since a finite field is, by definition, finite. Why would having an entirely neutral name be better? A finite field isn’t a field that is in some sense finite or related to or inspired by finiteness in some mysterious way, it is quite literally finite (in the sense that all mathematicians use the word). The danger of using existing terms like ‘category’ for new concepts is that they encourage the importation of lots of likely irrelevant associations and intuition that is likely to confuse rather than aid one’s understanding. I definitely think your argument goes too far if you think the phrase ‘finite field’ is potentially misleading. You might as well demand that the phrase ‘multiples of 5’ be replaced with ‘fluffies’ because it has less meaning.
- FooBarBizBazz 3y agoNames like "Steve" and "Pluto" take too long to type. Since the meanings are arbitrary anyway, you should just use A, B, C, etc. If you have a need for more than 26 names, you can start to also use letter pairs. For increased efficiency, a nightly job can compute the use-count of each referenced object, and assign it a new name according to an alphabetic Huffman code. This will minimize the amount of typing that developers have to waste their time doing. Many languages also do allow Unicode, including emojis, so this opens up additional options which may stand out better visually. I'm joking obviously. I think you should make an effort to give descriptive names to things, and that, as code changes, you should judiciously refactor and rename. An important purpose of code is to be read and to be understood. However, unnecessary and impenetrable jargon can be useful for protecting a niche in an organization, just as languages incomprehensible to outsiders (say, Gaelic) can be useful in nationalist projects. When the hammer of Management comes down to say Thou Shalt Write it in Java, it is like L'Academie Francaise stamping out some dialect in the Pyrenees, or extending its influence over Algeria. So that can be a reason for choosing special names known only within your team, or for writing it in Haskell or Rust.
- robbles 3y agoI once inherited a codebase that did this, and it was a nightmare to learn. All the classes were named after types of alcohol for some reason. Naming things clearly is really hard, but this approach is just giving up completely.
- hengheng 3y agoI wouldn't want that for my math scripts, either.
- Asraelite 3y agoIt needs the right balance. 95%+ of classes absolutely should not do this, but it's great for the handful of times when a class is complex, nuanced, and used prolifically. Assuming good documentation, it just means a few extra minutes learning what some terms mean, and that's worth it in the long run in my experience.
- ted_bunny 3y ago> the handful of times when a class is complex, nuanced, and used prolifically Is there a way to describe an example of such a class? That sounds like it could have a proper descriptive name, it'd just be a bit harder to come up with.
- jquast 3y agoHard disagree. Please everyone name it what it is, and don’t try to be coy or clever. Call it the metrics database, the example.com web service, the marketing tool, the data acquisition service, etc. I really hate that most private code bases are named “Steve” or similar, in a sea of micro services with Stacey and Stans and then there’s Steve 2.0 projects, and the only thing they bothered to document in the readme is the origin story and maybe a cute meme picture to go with it. And all of those people are gone and I’m a new employee and it’s not funny anymore. Everybody please just be serious, name it what it is, and document private business code like a professional. You’re getting paid so please take your job seriously.
- datadrivenangel 3y agoAnd then the metrics database also stores the tracking timeline for physical deliveries, because the business decided that it had to cut corners and ship a feature urgently and they had just fired the CTO for standing up for quality engineering at the expense of velocity.
- AnimalMuppet 3y ago> This is the power of mathematics really. In mathematics, things are never named "Steve".
- still_grokking 3y agoPlease never do that. Think of how you would explain things to some external or new person. Compare: "You need to tune Steve so Lily doesn't get stuck". to "You need to tune the data collection service so the object storage service doesn't get stuck". The first proposed variant is just ridiculous! Whereas the second variant gives you a glimpse of what's going on. For the exact same reason you should not call your identifiers in code "liz" or "bobo". Name your things what they are!
- paulddraper 3y agoThis is HN Big Brain approach to the problem of naming things.