Hacker News Reader

Comment by rhacker | Hacker News Reader

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.

View on HN

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.

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

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

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.

The comments on your linked post seem to indicate that NS referring to "NeXT & Sun" is highly controversial.

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

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.

If comfortable disclosing, what was said code 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 wonder how much open offices comingling sales/marketing/engineering has contributed to this kind of dysfunctional crossing the streams.

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.

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...

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.

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.

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

Last time I did iOS stuff, coding around iCloud everything was called UbiquityContainers or something.

as long as they were ubiquitous and containers I have no objection.

It requires discipline and good review practices to consistently use either marketing or technical identifiers in any given layer, including UI and API.

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

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

Reply on news.ycombinator.com