Fighting back against proper noun feature names (2021)(kubie.co)
kubie.co
Fighting back against proper noun feature names (2021)
https://kubie.co/blog/fighting-feature-names/
25 comments
Although I do design things, I'm not a manager so maybe this is just outside my job description, but how do you "hang" during a design process? What does it mean? Leave it for bit and see? Honest question.
It means being able to participate in the conversation, understand what is being proposed, and make useful decisions in the moment.
Not having data is not the equivalent of only talking in opinions. I will tell you rhat gathering data can and usually is tedious in many things. If I have to measure every single thing to make any argument, I'm quitting. Looking and thinking in data isn't a bad idea, but if it's just used as a crutch in an argument, then what I think the OP is arguing is that their manager is using it as a tool to make decisions but likely only the decisions they disagree with. As an engineer, I know many times that changes I make are going to work better, sans some fancy chart. If they're not, I think they'll show up on a graph one way or another and I think it's also healthy to be told my assumptions are wrong sometimes and I will happily revert my code. But I've never seen any org make purely data driven decisions as it is truly difficult to do, and whoever is saying things like that probably is selectively using that argument to get their way.
The odds of "the data" being gathered in a rigorous enough manner to have any truth value is exceedingly low. It's mostly a tactic to avoid accountability, much like consultants and committees.
[deleted]
> I really don't understand how asking to see data and talk in facts, rather than opinions, is a bad thing? This take seems to be implying the "design process" is just a giant, strictly qualitative "appeal to authority" fallacy and anyone who doesn't "get it" is some kind of naive rube?
I don't think you're quite understanding the context when this happens and why it's a sign of a weak manager.
The team is discussing a new design. A disagreement comes up: what should the text on this button say? Both sides seem to have good arguments, but the manager doesn't know how to pick between them. What to do?
"Do we have any data on this? Maybe we should run an A/B test?"
But no A/B test is needed: this is text on a button that doesn't have a meaningful conversion rate, it's just about clarity. The data we gather will not be useful. The problem is the manager didn't want to be seen as picking sides or playing favorites, or just doesn't understand what's happening, so they moved their own responsibility to an "objective, external measurement" to avoid making a decision.
Generally, "data-driven" is a buzzword that means "we manipulate statistics to do what we wanted to do anyway".
I don't think you're quite understanding the context when this happens and why it's a sign of a weak manager.
The team is discussing a new design. A disagreement comes up: what should the text on this button say? Both sides seem to have good arguments, but the manager doesn't know how to pick between them. What to do?
"Do we have any data on this? Maybe we should run an A/B test?"
But no A/B test is needed: this is text on a button that doesn't have a meaningful conversion rate, it's just about clarity. The data we gather will not be useful. The problem is the manager didn't want to be seen as picking sides or playing favorites, or just doesn't understand what's happening, so they moved their own responsibility to an "objective, external measurement" to avoid making a decision.
Generally, "data-driven" is a buzzword that means "we manipulate statistics to do what we wanted to do anyway".
It's the old joke about tossing a coin so you can realize what you root for, just in real life.
A tangentially related pet peeve of mine is using code names for everything internally. They’re fine in moderation, but should be used sparingly.
It’s easier for a new engineer to understand and remember that your “foo-retriever” service calls “foo-processor” than to keep track of how “Zephyr” interacts with “Ceres”
It’s easier for a new engineer to understand and remember that your “foo-retriever” service calls “foo-processor” than to keep track of how “Zephyr” interacts with “Ceres”
In Laravel, every single feature has a name like "Vapor" or "Forge" or "Octane" or "Dusk". I toyed around with Laravel a few months back, and ended up bouncing off it pretty quickly, because I simply couldn't remember what anything was.
"My account" is innocent enough, compared to some other real life examples. And it sometimes doesn't come from marketing, but from development too.
I've worked in company which added a "funny" codename to everything: features, libraries, sprints, sections of backoffice interface. I don't know, maybe for some developers it makes things more engaging, for me it added a ton of unnecessary stuff to memorize or look up.
Also one of the reasons I don't like AWS. You really can call a router just "router", virtual machine "virtual machine" and so on.
I've worked in company which added a "funny" codename to everything: features, libraries, sprints, sections of backoffice interface. I don't know, maybe for some developers it makes things more engaging, for me it added a ton of unnecessary stuff to memorize or look up.
Also one of the reasons I don't like AWS. You really can call a router just "router", virtual machine "virtual machine" and so on.
I also don't like AWS's odd names, but there are competing priorities when choosing to name something. I thought of some things to consider when you're naming which may make you choose a (possibly terrible) proper noun instead of a generic term.
* Is what you're naming a product which you can trademark? Or is it just a feature that would be silly to trademark? (EC2, Sagemaker, CloudFront vs account, billing profile, user)
* Does the name help with people differentiating your product from your competitors product?
* Does the name help people find the product when searching online?
* Does the name help ensure that the product isn't regarded as "Just a (generic term)" when it is more than that?
* Is what you're naming a product which you can trademark? Or is it just a feature that would be silly to trademark? (EC2, Sagemaker, CloudFront vs account, billing profile, user)
* Does the name help with people differentiating your product from your competitors product?
* Does the name help people find the product when searching online?
* Does the name help ensure that the product isn't regarded as "Just a (generic term)" when it is more than that?
My Account is not too bad but I dislike the trend towards calling every customer portal “MyAcme(TM)”
Literally yesterday I saw a message on one of these saying “Log into your MyAcme” - announcing the top issue with this naming scheme to everyone.
Literally yesterday I saw a message on one of these saying “Log into your MyAcme” - announcing the top issue with this naming scheme to everyone.
Tangentially related: memberships and their 'benefits' is something commonly used to disconnect the payment from the thing you get. You think it's extra. It's not. In fact, I don't use most of the 'benefits' and I'm still paying for them.
And the other weird use of language is showing a discount for when you get a credit card as 'take 5%'. Not 'take 5% off'.
Like, I don't get to 'take' that. It doesn't appear in my pocket. I'm just spending less on your already overpriced product.
And the other weird use of language is showing a discount for when you get a credit card as 'take 5%'. Not 'take 5% off'.
Like, I don't get to 'take' that. It doesn't appear in my pocket. I'm just spending less on your already overpriced product.
This is a rare advantage nonenglish programming teams have.
We have additional namespace for free. If it's the class it's account. If it's just an account it's konto or however you say account in your language.
Sometimes stuff is overloaded many times. Like transaction the user makes with the company, the DAO entity representing it, the db transaction, the spring transaction...
We have additional namespace for free. If it's the class it's account. If it's just an account it's konto or however you say account in your language.
Sometimes stuff is overloaded many times. Like transaction the user makes with the company, the DAO entity representing it, the db transaction, the spring transaction...
Counterpoint: if you are giving a user instructions (how tos, support interactions etc) then having the buttons, and concepts clearly marked out is really helpful.
E.g. if support tells a customer "click on your account" - then what does that mean? account is a generic abstract thing, how does one click on that? The customer must deduce that support is referring to one particular button on one particular place. Or support must say "the button labeled 'account' on the top right hand corner of the screen". If there is a unique name, then saying "click on 'Your Account"' is simpler.
It's even more critical when support needs to explain something abstract to a customer. Like, imagine explaining the difference between the temporary and EBS storage of a EC2 instance without any of the capitalized feature names.
E.g. if support tells a customer "click on your account" - then what does that mean? account is a generic abstract thing, how does one click on that? The customer must deduce that support is referring to one particular button on one particular place. Or support must say "the button labeled 'account' on the top right hand corner of the screen". If there is a unique name, then saying "click on 'Your Account"' is simpler.
It's even more critical when support needs to explain something abstract to a customer. Like, imagine explaining the difference between the temporary and EBS storage of a EC2 instance without any of the capitalized feature names.
I hope this idea makes the rounds. It's so terrible when you have to learn the idiosyncratic nomenclature of products.
It feels like it was already worse some years ago, but this piece spells it out. And, ironically, gives the problem a name, which is a good thing in this case.
It feels like it was already worse some years ago, but this piece spells it out. And, ironically, gives the problem a name, which is a good thing in this case.
Specifying "My Account" implies potential access to someone else's account, but marketing and security rarely meet.
"Features", like hurricanes?
Naming them is stupid, it's emotional and irrational.
The Japanese have a much better system of numbering them...
Naming them is stupid, it's emotional and irrational.
The Japanese have a much better system of numbering them...
Yeah it's weird. Didn't it start with Jobs?
I'd say "I'm going to Harrods", but never "has anyone seen iPhone?" to mean my iphone.
They've been trying this for over a decade and it still just sounds jarring.
I'd say "I'm going to Harrods", but never "has anyone seen iPhone?" to mean my iphone.
They've been trying this for over a decade and it still just sounds jarring.
Car manufacturers do it too - "Camry is safer than Accord" or something like that. (Maybe it's the other way around.) I'm not sure when it started.
"Please place the Aperture Science Weighted Storage Cube on the Aperture Science Super-colliding Super-button".
[deleted]
> In my experience, “show me the data” is often a tactic employed by weak managers who don’t know how to hang as part of a design process.
I really don't understand how asking to see data and talk in facts, rather than opinions, is a bad thing? This take seems to be implying the "design process" is just a giant, strictly qualitative "appeal to authority" fallacy and anyone who doesn't "get it" is some kind of naive rube?