Unfortunately this is a version of the thing it's trying to stop, as is plain from the below. These balls of mud are immune to negation; they laugh at it and grow stronger.
Also, they know what their sales cycles look like. They hear feedback from actual customers. They have people whose job it is to notice any advantage they could have along the way. And yet! They're still selling stuff, they're at 1.0, and they're still alive — with the name they have.
I think the dismissal that business people won't look at it because of the name is purely opinion-based. But what do I know?
https://en.wikipedia.org/wiki/Minor_characters_in_Bloom_Coun...
HN users are giving vital advice, for free. Those who ignore it will have only themselves to blame.
As I say every time this comes up, would you be so dismissive about critics of naming a product PubesDB? Or GonorrheaDB? Or [n-word]DB? Then you agree that disgust-invoking connotations of the name matter, and we're just haggling over the details.
Ubuntu, Mongo, Swagger (edit: Hadoop also) ... they're weird, sure, but they don't evoke the visceral feeling of disgust that cockroaches do.
It so far appears not to be hurting them. In the slightest.
This "warning" comes from the HN crowd every time something is posted about CockroachDB. I think it's time to LET IT GO.
I for one, completely disagree with you but that's because I have a different understanding of the relationship between the business side and engineering. We are already looked at as eccentric and strange people, rarely if ever has an absurd technology name caused issue.
Someone talking about "cockroach" is equivalent to talking about "unicorns" or "git." Its considerably less offensive than talk of "masters" and "slaves." If you think this is such a problem for you, then work on your salesmanship as I wouldn't hesitate to talk to other departments or investors about this product.
I was a CTO up until I took medical leave this past October and I cannot stress how important salesmanship is to the role. I think your examples of other databases are hyperbole and not the point. You want them to be equivalent but they aren't. This comes down to what you can sell in your organization and if there is merit to it, then selling it should not be a problem.
One last point is other departments don't give a shit what the database technology is called unless it's something to put on their CV. Just call it the "database" as they most certainly will.
I feel like that is tough to judge because the public has only known them by one name as far as I know. If they switched to this name from another name and saw no difference then we could surmise that the name has had no affect.
https://www.crunchbase.com/organization/cockroach-labs#/enti...
Your statement that it "absolutely will hurt adoption" is unqualified and nothing but opinion. And what exactly is "more successful?"
The handful of people who won't try this because of the name won't matter to their bottom line. If it's good enough then for even a large majority of those they'll end up using it anyway.
Pretty much any reasonable definition will do. For example, higher adoption is one metric that can be used to define success.
> Your statement that it "absolutely will hurt adoption" is unqualified and nothing but opinion.
It's an opinion that a lot of people share, judging from the HN threads I've seen about CockroachDB. And really, I shouldn't need to defend the idea that having a name that disgusts people will hurt adoption. It's just common sense. The only real question is how much damage will the name do? The better the product is, the more people will forgive things like bad names, but there will definitely be at least some level of damage.
In addition, if there's multiple products in the same category that are fairly close in quality, then subjective things like names will matter more. Maybe CockroachDB is significantly better than the alternatives right now (I really have no idea; this product category isn't something I know anything about), but if so, surely it won't remain "significantly better" forever. Other products will catch up, or other products will be created to compete, and we'll end up with several products that are similar, and once again, naming will become more important.
And finally, you're completely ignoring the fact that a lot of decisions about tech stack aren't actually made by technical people. They're frequently made by managers rather than engineers. And when the decision is made by non-technical people, marketing (e.g. name) is very important. Heck, even when the product is made by engineers, marketing is important, because that's how you convince the engineers to spend the time investigating the product to see if it lives up to its claims or does what they need.
Speaking as an engineer, if tomorrow I suddenly have the need for a cloud-native NewSQL database, I'm probably not even going to look at CockroachDB, simply based on the name, unless someone else convinces me that it's clearly superior. I find the name very off-putting and I'd rather not be confronted with the mental imagery of cockroaches any time I use the product.
You can't know how many VCs didn't fund due to the name or how many tech decision-makers at companies will pass on this product due to the name. That being said, I doubt it will be/was significant in any case.
It will never be let go, because each new person is a new interaction with the system that prompts the same point again.
It's like those '*porn' subreddits. You can explain and explain 'till you're blue in the face why the subs are so named, but there will always be some sniggering discussion when it is introduced to new users no matter how much you try and silence or control for it, because it's based on a natural response.
Capitalize all you like, but that's just how people work. :)
Still seems like bikeshedding.
It's not your company. You're (probably) not an equity holder. Have you personally been harmed by the name because your company wouldn't let you adopt it in spite of its technical merits? Are you worried it won't succeed because of the name and thus are fighting on the company's behalf for its survival?
> Most people ... and others you need to appeal to ... don't want anything to do with cockroaches
You're making so much of this up out of thin air.
> giving vital advice, for free
> As I say every time this comes up
As the parent said, the staff have already seen these messages. They have decided to keep the name. Advice is helpful, but once the decision is made, it's not. Let it go.
It is both a negative reaction and is memorable. It is not clear which wins, and it isn't your job to decide. Yes, you have an opinion but you may not be right.
I remember in the mid-2000s thinking that a particular politician couldn't possibly succeed with a Muslim sounding name. Turns out that a lot of people thought that. Yet Barack Hussein Obama managed to become President.
Your opinion has definitely been registered. Continuing to state it has no value.
So here's my question to you: could you be wrong about this having "concrete effects on adoption"? And if you are wrong, is this just bike shedding?
And to continue the bike shed metaphor, it's about people ignoring nuclear power plant design whose worst case scenario is nuclear meltdown. For CockroachDB 1.0, what's the equivalent, data loss? So are you discussing something technically trivial (colour is easy to understand) over the design (technically complex) that would prevent data loss? If the answer is yes, aren't you bike shedding like a champion?
tl;dr Bike shedders don't know they're bike shedding and think the discussion is very important.
I would appreciate your thoughts.
With respect to your specific point: if we could resolve how much it matters, then yes, that would obviate the debate. But the bikeshedding metaphor doesn't add much there because it's precisely in dispute about how much it matters.
I agree that it resolves to how much it matters, and I guess I disagree with you on how much it matters. How it relates to the bike shedding metaphor is starting to feel like a semantic argument, which is not something I want to continue.
In response to your escalated names like PubesDB... my opinion is that I agree I wouldn't work with them, not because of any internal disgust reaction, but because the name signals a level of maturity that I don't want in my stack. Some people might have the same reaction to Cockroaches.
I didn't feel it was abrasive at all.
For my part, I'm just upset that I went to such great lengths (in the comment I linked) to unpack where the bikeshed metaphor does or doesn't apply, disentangling the various issues and merging them into a general understanding, right where that comment was needed, and yet that's the one that no one is responding to... (what's worse, it was downvoted less than a minute after I posted it ).
>In response to your escalated names like PubesDB... my opinion is that I agree I wouldn't work with them, not because of any internal disgust reaction, but because the name signals a level of maturity that I don't want in my stack. Some people might have the same reaction to Cockroaches.
Right, like I said, "we're haggling over the details"; it should be regarded as a question of which names are so disgusting to be out of the question, yet people are dismissing the entire naming issue as "lol emotional primates".
Not taking a stance either way on the name, but that is the definition of bike-shedding (aka law of triviality). A committee won't vote for my nuclear plant because the bike shed is red. The bike shed's color has concrete effects on adoption.
EDIT: I would just like to acknowledge the irony of bike-shedding bike-shedding.
> ...but that is the definition of bike-shedding (aka law of triviality)
> A committee won't vote for my nuclear plant because the bike shed is red.
> The bike shed's color has concrete effects on adoption.
> Parkinson observed that a committee whose job is to approve plans for a
> nuclear power plant may spend the majority of its time on relatively
> unimportant but easy-to-grasp issues, such as what materials to use for
> the staff bikeshed, while neglecting the design of the power plant itself,
> which is far more important but also far more difficult to criticize constructively.
> -- https://en.wiktionary.org/wiki/bikeshedding
> A reactor is so vastly expensive and complicated that an average person cannot
> understand it, so one assumes that those who work on it understand it. On the
> other hand, everyone can visualize a cheap, simple bicycle shed, so planning
> one can result in endless discussions because *everyone involved wants to add a
> touch and show personal contribution*.
> -- https://en.wikipedia.org/wiki/Law_of_triviality
> -- https://books.google.com/books?id=RsMNiobZojIC&pg=PA317If I were to rephrase those two excerpts:
> Parkinson observed that a committee whose job is to approve plans for a
> [globally distributed relational database] may spend the majority of its time on relatively
> unimportant but easy-to-grasp issues, such as what [the name is],
> while neglecting the design of the [globally distributed relational database] itself,
> which is far more important but also far more difficult to criticize constructively.
> A [globally distributed relational database] is so vastly expensive and complicated that an average person cannot
> understand it, so one assumes that those who work on it understand it. On the
> other hand, everyone can [read a name], so planning
> one can result in endless discussions because *everyone involved wants to add a
> touch and show personal contribution*.
It's so meta it hurts.
The bikeshed story is to illustrate overemphasis on something that is trivial. It uses the example of a bikeshed color and a committee wanting to spend a lot of time on it because a) they care a little about it, and b) they understand it well enough for hard-headed members to wade into the dispute rather than trust experts.
It's a failure mode -- by stipulation -- because the bikeshed color doesn't matter beyond minor (but real) aesthetic feelings among the committee, that are far outweighed the cost of high-level personnel devoting time to it. Had they been aware of the general dynamic of these thing, they could entirely prevent the loss by moving on; it's purely an internal matter.
The bikeshed model ceases to demonstrate a failure mode if and when the bikeshed color has impacts far beyond things under the control of the committee. For example, if the majority of the world's people had a near-religious devotion to destroying facilities that house a blue bikeshed, and that fanaticism was hard to defend against, this would be a valid reason not to make the bikeshed blue, and would warrant the committee's attention.
I summarize such situations as "that's not bikeshedding", though of course, to be more technically correct, I should say "that situation does not illustrate the avoidable failure mode in the parable of the bikeshed".
Similarly, if adoption matters for more than just that committee -- if they need to convince numerous other committees to adopt the design -- it's likewise "not bikeshedding" because the first committee doesn't have control over all the other ones; with respect to the first, it's an external matter, and they can't stem the loss just by saying "hey, this is trivial".
Now, you are correct that, a high enough level, this could work as a bikeshedding example, if you could simultaneously get the entire world to collectively agree on the non-importance of aesthetics on technical matters, and on what counts as technical vs aesthetic. Then the world could play the role of that first committee and say "wow, this is trivial" and it's done.
But if that were actually feasible, then that should be your product (producing universal agreement on matters where you have a logical proof-of-correctness), not a database!
They don't need to appeal to any of these suits. Just the technical decision-makers, whose express job it is to choose solutions on their technical merits, not their spurious emotional reactions.
So these Suits you speak of, won't be able to get past the product name, enough to hear any technical merits of why this technology should ever be considered. Due to disfunctional leadership not even having a role of Chief Technical officer, or Chief Informational officer at the senior leadership level. A lot outsource because they don't want to hire/pay for this in house. It also shifts responsibility away, giving the CEO,COO,CFO, etc... the ability to point fingers at an outside entity.
That is a double whammy! internal can't sell/justify it to management, and outside IT providers/contractors can't sell it either.
So while they may be surviving with the current name they have, that does not mean they wouldn't be crushing the market share with a different name. If they are getting negative comments about the product name, then that's a warning that they should do market research to find out how many people would avoid the product because of the name.
But what the hell do I know, I'm making yet another HN comment post.
There was similar criticism about their name in the early days, but it has waned as mongo has grown. This will too.
Oh man, that's too much. lolol
The Spanish Wikipedia suggests many usages of the term "mongo", which probably wouldn't persist if the term was so repulsive: https://es.wikipedia.org/wiki/Mongo
Edit: Now that my memory kicked in, it's racist as well.
Is "mongo" the equivalent of English "retard", in terms of being a low-class insult that invokes a visceral reaction among the majority of the population?
I didn't believe that at first; if so, why didn't anyone ever put it in Wikipedia? English has "retard" (in the pejorative sense):
https://en.wikipedia.org/wiki/Retard#Other_uses
And why doesn't it show up in a top-result Spanish dictionary?
http://www.spanishdict.com/translate/mongo
If it's merely an insult with numerous other meanings, I don't think it's comparable.
But let's assume it is equivalent to "retard". In that case, I would agree that it shouldn't be used as a name. But you have to pick your battles: all words will have that trait in some language. For my part, I would consider the Spanish-speaking market big enough not to expect them to buy [the equivalent of] RetardDB. So I agree there.
Edit: I agree with the sibling commenter networked's points.
Now, even if I had associated MongoDB with that explanation, and now that I do remember it's inherent meaning under a certain context, I take no offense in it since the people behind MongoDB didn't have that intent. Obviously this is an assumption on my part.
Let us not get derailed from the main point, which is the 'visceral' feelings that cockroachDB has on so many people as you mentioned in several comments. It is true, it happens to me as well. But not the word itself, but when I'm around one. Those feelings of fear, whatever, when around one are irrational. I don't remember the explanation why it's irrational, I've never worked in the field of psychology.
Maybe you have to be culturally immersed to know those things. Mongo, mongol and mongólico are the terms you should research.
I specifically said I would be sensitive to the offense it would cause in other languages, at least the major ones.
- SQLite: SQL database with no sugar. Less calories!
- MySQL: A selfish database.
- IMB DB2: Released in 1983, but never got promoted to DB3. Probably abandoned software?
- Postgresql: Gesundheit!
- CouchDB: A database for lazy people. Part of the NOSQL family, the Zen database family, that achieve SQL by not achieving SQL... like I said, lazy.
- Microsoft Access: It's very accessible. Ironically, most people that use Office don't know what it is, or that it exists, and thus, don't use it.
- dBase: De-bases your data.
- Sybase: Pronounced sigh base, which is the sound people make when you suggest it.
MySQL is named after the founder's daughter "My". The fork is named after his other daughter "Maria": https://en.wikipedia.org/wiki/Michael_Widenius#Personal_life
MySQL: a proprietary product if ever I saw one.
CouchDB: wow, does that hide bits of data until you search next week?
So now the top thread is about how terrible HN is for bikeshedding instead of talking about the actual topic... except this top thread is also not talking about the actual topic. Worth considering, imo.