4 ms·

While I don't agree with the author AT ALL. I think products need two names: a marketing name and a code name. I was at a company that kept renaming the marketi

While I don't agree with the author AT ALL. I think products need two names: a marketing name and a code name. I was at a company that kept renaming the marketing name. And for some reason I couldn't get the programmers to stop spending weeks redoing packages: com.companyname.integrationhub to com.companyname.superconnector. I kept trying to tell people that the marketing name is going to change all the time and that the package we put it under should be very different from the marketing name - on purpose, so that we don't need to repackage it every 2 weeks. Call it com.companyname.dataintegrator. The marketing name of the data integrator can change all day long and its package must remain dataintegrator.

kevincox 4y ago
100%. I was at a company and they kept renaming the internal name to match the marketing name. We had 3 names for some older tech and 2 names for the less than a year old service. I strongly recommended that we should adopt the original name as a "codename" and use it for code and internal technical documents. Marketing should absolutely have full control over the user visible name. But technology has different needs where a "codename" is a much better match. Having two names is generally only a tiny bit confusing. I have also yet to see a codebase rename that completes before the product name changes again. You always just end up with a confusing slew of N names in the codebase if you try to rename.
- pphysch 4y ago
  It seems that most business objects should have all of the following: 1) A memory-friendly, indexed, unique, immutable ID (e.g. BIGINT or GUID). 2) A human-friendly unique immutable codename/slug. 3) A human-friendly mutable marketing/display name. 1 & 2 could be combined in some cases
- dlivingston 4y ago
  Related-ish, but Apple's macOS APIs are peppered with references to NeXTSTEP. I find this charming. For example, NSView (spelled out - NextStepView). https://developer.apple.com/documentation/appkit/nsview https://developer.apple.com/documentation/appkit/nsview
  - aaronbrethorst 4y ago
    NeXTStep used "NX" prefixes, and its successor, OpenStep, used the prefix "NS". "NX" stood for "NeXT", "NS" stood for "NeXT and Sun". https://news.ycombinator.com/item?id=15973609 https://news.ycombinator.com/item?id=15973609
    - dlivingston 4y ago
      The comments on your linked post seem to indicate that NS referring to "NeXT & Sun" is highly controversial.
    - spfzero 4y ago
      IIRC the NS prefix was in use long before there were any dealings with Sun. There was software development going on at NeXT before they had the name for the OS ("NeXTStep"). So, NX for NeXT, NS for NeXTStep.
wruza 4y ago
I mostly agree, although from a user side it’s sometimes confusing to encounter random identifiers barely mentioned anywhere.
- dottedmag 4y ago
  It requires discipline and good review practices to consistently use either marketing or technical identifiers in any given layer, including UI and API.
- jcampbell1 4y ago
  Last time I did iOS stuff, coding around iCloud everything was called UbiquityContainers or something.
  - banku_brougham 4y ago
    as long as they were ubiquitous and containers I have no objection.
aendruk 4y ago
I tried this once and marketing latched on to my deliberately stupid code name and used it for the public release. My protest was unable to sway them.
- dlivingston 4y ago
  If comfortable disclosing, what was said code name?
banku_brougham 4y ago
This is not an effective argument in disagreement with the OP.
- layer8 4y ago
  I don’t think it was supposed to be, given the introductory “while”.
pengaru 4y ago
> And for some reason I couldn't get the programmers to stop spending weeks redoing packages: com.companyname.integrationhub to com.companyname.superconnector. I wonder how much open offices comingling sales/marketing/engineering has contributed to this kind of dysfunctional crossing the streams.
WuxiFingerHold 4y ago
I agree in that the need to refactor large amounts of code because of changes in the marketing product name is insane. If the devs had just ignored the change the first time (kept the name integrationhub) the separation would have happened naturally.
Scea91 4y ago
Would you extend this to all names and not just product? I attempt to push domain driven design and one of the principles is that a single concept should be called by a single name. It all works well until product management decides to unilaterally push renaming of of concept in UI for vague 'market' reasons...
- dottedmag 4y ago
  I do. In my current project there is a rule: if marketing touches it, it's not a name, it's a label. Starting from the code repository and down to the variables names, only technical identifiers are treated as stable.
danmur 4y ago
Yep. All my personal projects I give a name that's related to the subject but will never be a public name. Helps a lot with naming paralysis.

kevincox 4y ago

100%. I was at a company and they kept renaming the internal name to match the marketing name. We had 3 names for some older tech and 2 names for the less than a year old service. I strongly recommended that we should adopt the original name as a "codename" and use it for code and internal technical documents. Marketing should absolutely have full control over the user visible name. But technology has different needs where a "codename" is a much better match. Having two names is generally only a tiny bit confusing. I have also yet to see a codebase rename that completes before the product name changes again. You always just end up with a confusing slew of N names in the codebase if you try to rename.

pphysch 4y ago
It seems that most business objects should have all of the following: 1) A memory-friendly, indexed, unique, immutable ID (e.g. BIGINT or GUID). 2) A human-friendly unique immutable codename/slug. 3) A human-friendly mutable marketing/display name. 1 & 2 could be combined in some cases
dlivingston 4y ago
Related-ish, but Apple's macOS APIs are peppered with references to NeXTSTEP. I find this charming. For example, NSView (spelled out - NextStepView). https://developer.apple.com/documentation/appkit/nsview https://developer.apple.com/documentation/appkit/nsview
- aaronbrethorst 4y ago
  NeXTStep used "NX" prefixes, and its successor, OpenStep, used the prefix "NS". "NX" stood for "NeXT", "NS" stood for "NeXT and Sun". https://news.ycombinator.com/item?id=15973609 https://news.ycombinator.com/item?id=15973609
  - dlivingston 4y ago
    The comments on your linked post seem to indicate that NS referring to "NeXT & Sun" is highly controversial.
  - spfzero 4y ago
    IIRC the NS prefix was in use long before there were any dealings with Sun. There was software development going on at NeXT before they had the name for the OS ("NeXTStep"). So, NX for NeXT, NS for NeXTStep.

wruza 4y ago

I mostly agree, although from a user side it’s sometimes confusing to encounter random identifiers barely mentioned anywhere.

dottedmag 4y ago
It requires discipline and good review practices to consistently use either marketing or technical identifiers in any given layer, including UI and API.
jcampbell1 4y ago
Last time I did iOS stuff, coding around iCloud everything was called UbiquityContainers or something.
- banku_brougham 4y ago
  as long as they were ubiquitous and containers I have no objection.

aendruk 4y ago

I tried this once and marketing latched on to my deliberately stupid code name and used it for the public release. My protest was unable to sway them.

dlivingston 4y ago
If comfortable disclosing, what was said code name?

banku_brougham 4y ago

This is not an effective argument in disagreement with the OP.

layer8 4y ago
I don’t think it was supposed to be, given the introductory “while”.

pengaru 4y ago

> And for some reason I couldn't get the programmers to stop spending weeks redoing packages: com.companyname.integrationhub to com.companyname.superconnector. I wonder how much open offices comingling sales/marketing/engineering has contributed to this kind of dysfunctional crossing the streams.

WuxiFingerHold 4y ago

I agree in that the need to refactor large amounts of code because of changes in the marketing product name is insane. If the devs had just ignored the change the first time (kept the name integrationhub) the separation would have happened naturally.

Scea91 4y ago

Would you extend this to all names and not just product? I attempt to push domain driven design and one of the principles is that a single concept should be called by a single name. It all works well until product management decides to unilaterally push renaming of of concept in UI for vague 'market' reasons...

dottedmag 4y ago
I do. In my current project there is a rule: if marketing touches it, it's not a name, it's a label. Starting from the code repository and down to the variables names, only technical identifiers are treated as stable.

danmur 4y ago

Yep. All my personal projects I give a name that's related to the subject but will never be a public name. Helps a lot with naming paralysis.