You could always take the approach of JRR Tolkien: come up with the name first, then try to figure out what the software will do from that name. In a hole in a database, there lived a hobbit.
Software component names should be whimsical and cryptic
291–300 of 339 posts
Re: Software component names should be whimsical and cryptic
#292Think of the new people you hire! It is difficult enough being onboarded to a new company without having to learn two dozen names for random services and libraries. I feel sorry for each batch of Interns that start at companies that do this. Not only were the Interns learning how to build software but they also had to learn random names that they would not be able to use in their next placement. What is easier to und…
If only the names were so plain. Usually they’re longer with the intention of being plain, then they become opaque acronyms:
PPS stopped responding to UDMS. CMS is also down! No, not the CMS, the CMS is fine… CMS-the-service is down!
Re: Software component names should be whimsical and cryptic
#293I don’t think you need to go full startup when naming stuff, but you also don’t have to go full bureaucrat either. I once created a PHP framework called RocketSled because it was “the fastest thing on rails” and that gave rise to somewhat whimsical but also descriptive names on the same theme: RocketPack: package manager DataBank: caching auto loader Murphy: automated testing Each of those modules is named quite spec…
Where does Murphy come from?
Everyone else beat me to the explanation. The "Murphy" in Murphy's law also worked specifically on RocketSleds which is where the term "Murphy's Law" came from:
"Following the end of hostilities, in 1947 Murphy attended the United States Air Force Institute of Technology, becoming R&D Officer at the Wright Air Development Center of Wright-Patterson Air Force Base. It was while here that he became involved in the high-speed rocket sled experiments (USAF project MX981, 1949) which led to the coining of Murphy's law."
I was very pleasantly surprised by this coincindence when I was looking for a name for my testing package to go with my RocketSled framework. I named the framework RocketSled before I wrote the testing package, with no idea about the history of the term Murphy's Law.
Interesting side note: murphytest lives on to this day as an NPM package, I still use the same approach to testing stuff now (ie. not worrying about any of the tenets of "Unit Testing", a practise which I called "Convergence Testing" at the time, but which probably already has a name, like Integration Testing maybe).
Re: Software component names should be whimsical and cryptic
#294I very often whip out this tried by true joke. People often think it's "just a joke", but I actually think of it more as an adage, as words of wisdom, that also just happen to be whimsical.
There are only 2 difficult things in computer science:
1. Naming things
2. Cache Invalidation
3. Off by one errorsRe: Software component names should be whimsical and cryptic
#295I very often whip out this tried by true joke. People often think it's "just a joke", but I actually think of it more as an adage, as words of wisdom, that also just happen to be whimsical. There are only 2 difficult things in computer science: 1. Naming things 2. Cache Invalidation 3. Off by one errors
The number of times I've told it in an interview with a programmer and they don't laugh are horrifying. There's deep, memorable wisdom in there if you have any experience.
Re: Software component names should be whimsical and cryptic
#296Inside this essay giving horrible advice, is more horrible advice: > Even worse are those ubiquitous diagrams everybody uses to communicate about software, where there’s a box labeled OrdersService with an arrow connecting it to a box labeled OrderStatusService. I don’t understand why anybody draws those. People like this are why there are documents with a thousand bullet points and no diagrams to help anyone actuall…
This is a great diagnosis. I hate to assume things, but sometimes I almost get the impression that some software developers are pulling an "I am very smart" move by making things more cryptic than they need to be.
The ones who do that I've found to be less experienced. Once they've had to deal with their own bullshit, they tend to grow out of it. Even you don't know what that code you wrote a year ago is doing.
Re: Software component names should be whimsical and cryptic
#297Earlier quoted context omitted.
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.
You version your APIs, but do you version your services ?
Think of your new service as having a different deployment target, its own DB, and could be under a different repo altogether.
Re: Software component names should be whimsical and cryptic
#298Earlier quoted context omitted.
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…
> Those are full of breaking changes that you want to isolate from the legacy “UserProfile”, how do you name your new service ? Sound like it's better to make a new service. Isn't that the point of Single Responsibility concept?
You got me confused.
Re: Software component names should be whimsical and cryptic
#299> See, the scope and purpose of something changes faster than its name can. There's your problem. Create libraries that aim to do one thing and do it well. Once you release your project and have users that depend on your code, you owe it to them to maintain it in the original scope. If you have an urge to change your project's scope so much that the name should change, create a new library with a better name instead.…
> Create libraries that aim to do one thing and do it well.
This is a thing people like to repeat over and over again, but just really isn't actionable. The world is very high dimensional, it's always a judgement call what to cluster together and call "one thing". Especially in software where everything is made up and is constantly changing.
People often like to refer to things like unix tools etc as doing one thing and doing it well, but all those tools have grown a ton of command line args, and have backwards compatibility issues that prevent them from doing their job "well" in the modern era. So people write new tools or just hardcodes a ton of command line flags into aliases by default. Many default settings on unix tools are awful. Why does grep not use regex by default? Why doesn't echo support newline escapes by default? Which tools use color by default?
Reality is a mess, and it's an illusion that you can do "one thing"
Re: Software component names should be whimsical and cryptic
#300Earlier 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! "
Look at IBM "Watson". It had evolved from an AI jeopardy and Q&A engine into basically whatever salespeople make up.