If you call your data exporter "Asparagus" I will throw a thesaurus at you every day until you come up with a better name for it that has some kind of mnemonic link to what it does. "Data Exporter" is okay, but "Catapult" or "Superhighway" or another whimsical name would be okay too, so long as it loosely matches the problem domain in a memorable way.

“Yeet”

I personally would prefer my exporter to focus on precision, not distance.

So clearly, it wouldn't be "Asparagus", it would be "Beef" (as in Kobe).

I remember how confused I was when I found out a program exists called "FileMaker". Curious how that name was chosen.

Your comment really gave me pause. I've used FileMaker for many years but never gave the name that much thought.

I can't say how the name was chosen. But, I believe I understand the justification for it. It is pretty straightforward once the metaphor is clear. The files it is making are the type of files that go into filing cabinets, not the files on a computer. Early versions of the software had a logo/picture of a building that was a giant filing cabinet and the app logo has usually been a filing folder.

The name makes sense in that isn't about making files on a computer but to help small business convert physical files found in filing cabinets into digital ones in wysiwyg database.

I remember finding "Photoshop" nonsensical at first because I associated a shop with a place to go buy things and it only made sense once I made the association that cars and such are taken to the shop for repairs.

I'm still split on which category Adobe (Macromedia) Dreamweaver falls into.

Better be consistently boring than ever misleading

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!"

I've worked on tools that were slightly misnamed after 6 months, and completely misnamed after 2 years. At that point they were also usually just nearly useless due to feature bloat and/or lack of scalability, so deprecated or replaced with something better.

They didn't change names, but their successors would get a new one.

Yep, enough that they need a caveat every time someone new is told of the product. It happens, and it's gotten worse due to Agile.

Look at IBM "Watson". It had evolved from an AI jeopardy and Q&A engine into basically whatever salespeople make up.

Isn't it even harder to re-define names in a company? There might be 3 people involved in re-definition, but it affects 15 people.

How are we going to notify those 15? Do we even know who those 15 are? Are we going to create a weekly redefinition newsletter?

I think in most cases new meaning deserves a new name. Everything else is just hacks.

How hard is it to change a name is a actually a really good metric for a company. If a simple rename takes several days, multiple approvals, rounds of QA, and a scheduled release next quarter, then you probably need those hacks.

I think that's very extreme. Products grow at a gradual pace. I don't think there are defining moments when a product no longer supports something, or is no longer used in a way that it was intended to.

I would argue it's easier to maintain peoples understanding of a product since that will also be done gradually. It's not easy to update naming inside of a code base without potentially breaking software significantly or causing unknown bugs elsewhere. I think most software would fail the renaming test. It's also generally not worth the money and time needed to make that change.

Terrific answer!

No idea which way you're arguing though! ;)

Better to be googlable than boring.