Rebranding
-
Our company is being rebranded and we're to fall in line and change the colour scheme of our web application that's currently used internally and is in the process of being sold externally. Unfortunately, the name of our product and the new colour scheme means there may be a trademarking issue with another company who sound/look similar but whose business is pretty much completely different; to pre-empt any legal issues our sales team have decided to rename the software. The original name was chosen 3 years ago and the codebase/application database is built around it; management want the developers and internal users to start referring to it by it's new name (which they haven't even come up with yet), but that's kinda difficult when classes, methods, tables, stored procedures etc. are prefixed/contain the original name. To the development team it will always be known under it's original moniker. Should we have avoided using the name in the code/database and stuck to generic terms?? Anyone else had a similar problem? Having breathed the code for so long I can't imagine calling it anything different when nothing else is changing.
I'll let future me worry about that!
-
Our company is being rebranded and we're to fall in line and change the colour scheme of our web application that's currently used internally and is in the process of being sold externally. Unfortunately, the name of our product and the new colour scheme means there may be a trademarking issue with another company who sound/look similar but whose business is pretty much completely different; to pre-empt any legal issues our sales team have decided to rename the software. The original name was chosen 3 years ago and the codebase/application database is built around it; management want the developers and internal users to start referring to it by it's new name (which they haven't even come up with yet), but that's kinda difficult when classes, methods, tables, stored procedures etc. are prefixed/contain the original name. To the development team it will always be known under it's original moniker. Should we have avoided using the name in the code/database and stuck to generic terms?? Anyone else had a similar problem? Having breathed the code for so long I can't imagine calling it anything different when nothing else is changing.
I'll let future me worry about that!
Yeah, I've been through this before. I quite quickly got into using a certain name internally (amongst developers and other close workers), and a different name externally (customers and managers). I can think of a few external products I have used that have objects names based on the original product name, or even the original developing company where it has been bought out.
Every man can tell how many goats or sheep he possesses, but not how many friends.
-
Our company is being rebranded and we're to fall in line and change the colour scheme of our web application that's currently used internally and is in the process of being sold externally. Unfortunately, the name of our product and the new colour scheme means there may be a trademarking issue with another company who sound/look similar but whose business is pretty much completely different; to pre-empt any legal issues our sales team have decided to rename the software. The original name was chosen 3 years ago and the codebase/application database is built around it; management want the developers and internal users to start referring to it by it's new name (which they haven't even come up with yet), but that's kinda difficult when classes, methods, tables, stored procedures etc. are prefixed/contain the original name. To the development team it will always be known under it's original moniker. Should we have avoided using the name in the code/database and stuck to generic terms?? Anyone else had a similar problem? Having breathed the code for so long I can't imagine calling it anything different when nothing else is changing.
I'll let future me worry about that!
dimensionJumper wrote:
Should we have avoided using the name in the code/database and stuck to generic terms?? Anyone else had a similar problem?
Programming for Mac OS and iOS still have plenty API components with the NS prefix. NS stands for NextStep... Not to mention everything in MFC being prefixed with AFX. On one of our big projects we had a name that we (the developers) really wanted to be the release name, but marketing renamed it to a completely uninteresting number. Yes, just a number. Everything in the codebase still uses the original name, but no one really calls it that anymore.
-
Our company is being rebranded and we're to fall in line and change the colour scheme of our web application that's currently used internally and is in the process of being sold externally. Unfortunately, the name of our product and the new colour scheme means there may be a trademarking issue with another company who sound/look similar but whose business is pretty much completely different; to pre-empt any legal issues our sales team have decided to rename the software. The original name was chosen 3 years ago and the codebase/application database is built around it; management want the developers and internal users to start referring to it by it's new name (which they haven't even come up with yet), but that's kinda difficult when classes, methods, tables, stored procedures etc. are prefixed/contain the original name. To the development team it will always be known under it's original moniker. Should we have avoided using the name in the code/database and stuck to generic terms?? Anyone else had a similar problem? Having breathed the code for so long I can't imagine calling it anything different when nothing else is changing.
I'll let future me worry about that!
dimensionJumper wrote:
Should we have avoided using the name in the code/database and stuck to generic terms?
As much as reasonable, yes. I imagine the dB name would likely be fairly product specific and, (well at least from a .Net-ish point of view anyway), namespaces fairly commonly have the same thing happen but whenever possible I've always argued the toss to avoid the same happening with anything else.
Rhys "Technological progress is like an axe in the hands of a pathological criminal" "Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe"
-
Our company is being rebranded and we're to fall in line and change the colour scheme of our web application that's currently used internally and is in the process of being sold externally. Unfortunately, the name of our product and the new colour scheme means there may be a trademarking issue with another company who sound/look similar but whose business is pretty much completely different; to pre-empt any legal issues our sales team have decided to rename the software. The original name was chosen 3 years ago and the codebase/application database is built around it; management want the developers and internal users to start referring to it by it's new name (which they haven't even come up with yet), but that's kinda difficult when classes, methods, tables, stored procedures etc. are prefixed/contain the original name. To the development team it will always be known under it's original moniker. Should we have avoided using the name in the code/database and stuck to generic terms?? Anyone else had a similar problem? Having breathed the code for so long I can't imagine calling it anything different when nothing else is changing.
I'll let future me worry about that!
If the company wants to spend the time and money refactoring the code to use what moniker they end up with, you should do it. Let them drive the process: come up with the name, scheme, prefixes, etc. Just let them know how much time and effort it will cost. After all, they are your customers.
m.bergman
For Bruce Schneier, quanta only have one state : afraid.
To succeed in the world it is not enough to be stupid, you must also be well-mannered. -- Voltaire
-
If the company wants to spend the time and money refactoring the code to use what moniker they end up with, you should do it. Let them drive the process: come up with the name, scheme, prefixes, etc. Just let them know how much time and effort it will cost. After all, they are your customers.
m.bergman
For Bruce Schneier, quanta only have one state : afraid.
To succeed in the world it is not enough to be stupid, you must also be well-mannered. -- Voltaire
You're right, they do pay the wages and whatever name they feel would sell the product is up to them; I think my boss is taking it slightly personally as he came up with the original name etc. and he wasn't consulted about the name change at all.
-
Our company is being rebranded and we're to fall in line and change the colour scheme of our web application that's currently used internally and is in the process of being sold externally. Unfortunately, the name of our product and the new colour scheme means there may be a trademarking issue with another company who sound/look similar but whose business is pretty much completely different; to pre-empt any legal issues our sales team have decided to rename the software. The original name was chosen 3 years ago and the codebase/application database is built around it; management want the developers and internal users to start referring to it by it's new name (which they haven't even come up with yet), but that's kinda difficult when classes, methods, tables, stored procedures etc. are prefixed/contain the original name. To the development team it will always be known under it's original moniker. Should we have avoided using the name in the code/database and stuck to generic terms?? Anyone else had a similar problem? Having breathed the code for so long I can't imagine calling it anything different when nothing else is changing.
I'll let future me worry about that!
-
Our company is being rebranded and we're to fall in line and change the colour scheme of our web application that's currently used internally and is in the process of being sold externally. Unfortunately, the name of our product and the new colour scheme means there may be a trademarking issue with another company who sound/look similar but whose business is pretty much completely different; to pre-empt any legal issues our sales team have decided to rename the software. The original name was chosen 3 years ago and the codebase/application database is built around it; management want the developers and internal users to start referring to it by it's new name (which they haven't even come up with yet), but that's kinda difficult when classes, methods, tables, stored procedures etc. are prefixed/contain the original name. To the development team it will always be known under it's original moniker. Should we have avoided using the name in the code/database and stuck to generic terms?? Anyone else had a similar problem? Having breathed the code for so long I can't imagine calling it anything different when nothing else is changing.
I'll let future me worry about that!
dimensionJumper wrote:
Should we have avoided using the name in the code/database and stuck to generic terms?
Yes. Absolutely.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun -
Our company is being rebranded and we're to fall in line and change the colour scheme of our web application that's currently used internally and is in the process of being sold externally. Unfortunately, the name of our product and the new colour scheme means there may be a trademarking issue with another company who sound/look similar but whose business is pretty much completely different; to pre-empt any legal issues our sales team have decided to rename the software. The original name was chosen 3 years ago and the codebase/application database is built around it; management want the developers and internal users to start referring to it by it's new name (which they haven't even come up with yet), but that's kinda difficult when classes, methods, tables, stored procedures etc. are prefixed/contain the original name. To the development team it will always be known under it's original moniker. Should we have avoided using the name in the code/database and stuck to generic terms?? Anyone else had a similar problem? Having breathed the code for so long I can't imagine calling it anything different when nothing else is changing.
I'll let future me worry about that!
Database tables/SPs/etc should generally not have the application name in them, the database name itself should be all you need for that. In code, the convention seems to be that namespaces (whether literally supported in the language like C++/C#/Java or done by convention like in C with myapp_function) reflect the application name. Those can easily end up preserving an old name after a rebranding. But things within the namespace shouldn't use the app name in names, they should have names that make sense within the context of the problem your application is trying to solve.
-
Our company is being rebranded and we're to fall in line and change the colour scheme of our web application that's currently used internally and is in the process of being sold externally. Unfortunately, the name of our product and the new colour scheme means there may be a trademarking issue with another company who sound/look similar but whose business is pretty much completely different; to pre-empt any legal issues our sales team have decided to rename the software. The original name was chosen 3 years ago and the codebase/application database is built around it; management want the developers and internal users to start referring to it by it's new name (which they haven't even come up with yet), but that's kinda difficult when classes, methods, tables, stored procedures etc. are prefixed/contain the original name. To the development team it will always be known under it's original moniker. Should we have avoided using the name in the code/database and stuck to generic terms?? Anyone else had a similar problem? Having breathed the code for so long I can't imagine calling it anything different when nothing else is changing.
I'll let future me worry about that!
Story time... Way back when, the Powers That Be decided that we needed a new product line name. They decided that 'VersaMark' sounded cool, and told us to use that. There was a teeny-tiny question, though: is it spelled "VersaMark" or "Versamark"? As best as we could determine, the "VersaMark" spelling was preferred by most of the PHI's (Pointy-Haired Invertebrates) in sales, marketing, and service. We used the new name. A lot. Everything from source file names to install directories, UI text, registry key names, everything had "VersaMark" in it. Months pass. I get copied on some marketing materials related to our stuff, and they're using "Versamark". Oh crap. A few days later I'm in a meeting, and the VP of Sales makes the comment to one of his drones "it amazes me that Engineering can't even spell Versamark properly." I then spent 3 days changing "VersaMark" to "Versamark" everywhere, whether the string was visible to users or not. UI window captions, source file names, registry keys, install folders, everything. Our installers even quietly renamed folders and registry keys to ensure that the reviled upper case M would not be seen.
Software Zen:
delete this; -
Our company is being rebranded and we're to fall in line and change the colour scheme of our web application that's currently used internally and is in the process of being sold externally. Unfortunately, the name of our product and the new colour scheme means there may be a trademarking issue with another company who sound/look similar but whose business is pretty much completely different; to pre-empt any legal issues our sales team have decided to rename the software. The original name was chosen 3 years ago and the codebase/application database is built around it; management want the developers and internal users to start referring to it by it's new name (which they haven't even come up with yet), but that's kinda difficult when classes, methods, tables, stored procedures etc. are prefixed/contain the original name. To the development team it will always be known under it's original moniker. Should we have avoided using the name in the code/database and stuck to generic terms?? Anyone else had a similar problem? Having breathed the code for so long I can't imagine calling it anything different when nothing else is changing.
I'll let future me worry about that!
dimensionJumper wrote:
Should we have avoided using the name in the code/database and stuck to generic terms??
Definitely. The situation you described is only one of many that might result in different names originating from the marketing stand point. Consider "SQL Server" and "SQL Server Express" as one example of that. The code base is almost entirely the same. Probably the only difference is a flag bit somewhere. Or maybe one dll swapped with another.
-
Our company is being rebranded and we're to fall in line and change the colour scheme of our web application that's currently used internally and is in the process of being sold externally. Unfortunately, the name of our product and the new colour scheme means there may be a trademarking issue with another company who sound/look similar but whose business is pretty much completely different; to pre-empt any legal issues our sales team have decided to rename the software. The original name was chosen 3 years ago and the codebase/application database is built around it; management want the developers and internal users to start referring to it by it's new name (which they haven't even come up with yet), but that's kinda difficult when classes, methods, tables, stored procedures etc. are prefixed/contain the original name. To the development team it will always be known under it's original moniker. Should we have avoided using the name in the code/database and stuck to generic terms?? Anyone else had a similar problem? Having breathed the code for so long I can't imagine calling it anything different when nothing else is changing.
I'll let future me worry about that!
As others have said, generic terms are best for a variety of reasons and this even is one of them. Another tactic some companies use is to refer to the project with an internal code name. In the end you will always have to make all visible names be correct for the product but the goal is to try to minimize the instances of those because we all know how fickle the marketeers can be.
-
Story time... Way back when, the Powers That Be decided that we needed a new product line name. They decided that 'VersaMark' sounded cool, and told us to use that. There was a teeny-tiny question, though: is it spelled "VersaMark" or "Versamark"? As best as we could determine, the "VersaMark" spelling was preferred by most of the PHI's (Pointy-Haired Invertebrates) in sales, marketing, and service. We used the new name. A lot. Everything from source file names to install directories, UI text, registry key names, everything had "VersaMark" in it. Months pass. I get copied on some marketing materials related to our stuff, and they're using "Versamark". Oh crap. A few days later I'm in a meeting, and the VP of Sales makes the comment to one of his drones "it amazes me that Engineering can't even spell Versamark properly." I then spent 3 days changing "VersaMark" to "Versamark" everywhere, whether the string was visible to users or not. UI window captions, source file names, registry keys, install folders, everything. Our installers even quietly renamed folders and registry keys to ensure that the reviled upper case M would not be seen.
Software Zen:
delete this;Went through a somewhat similar story with very similar consequences a long time ago. Since then, a lot of ex and current colleagues must think I'm a paranoid freak if a request is not documented and formally approved. Call me what you will, getting burned with something as big as a product name entitles you to being paranoid. Never assume that what seems trivial to you is trivial for other departments. Never assume that what you're asked is what they wanted. Having it documented will save a lot of pain and if worse comes to worse, the documentation can cover you a$$ if things go out of hand. That's experience I'm glad I earned early. Right up there with never never never use stupid test data, but that's another story :-O
-
Our company is being rebranded and we're to fall in line and change the colour scheme of our web application that's currently used internally and is in the process of being sold externally. Unfortunately, the name of our product and the new colour scheme means there may be a trademarking issue with another company who sound/look similar but whose business is pretty much completely different; to pre-empt any legal issues our sales team have decided to rename the software. The original name was chosen 3 years ago and the codebase/application database is built around it; management want the developers and internal users to start referring to it by it's new name (which they haven't even come up with yet), but that's kinda difficult when classes, methods, tables, stored procedures etc. are prefixed/contain the original name. To the development team it will always be known under it's original moniker. Should we have avoided using the name in the code/database and stuck to generic terms?? Anyone else had a similar problem? Having breathed the code for so long I can't imagine calling it anything different when nothing else is changing.
I'll let future me worry about that!
You prefixed your objects with the app info, are you nuts, I find most apps go through at least 3 name changes before the initial demonstration, the one I picked, the one the manager makes me change it to and finally the one the idiots in marketing (or IT) decide to call it. Database and App names are the only things that reflect the name. I also do not change them from my original naming, everything else the weenies can dictate.
Never underestimate the power of human stupidity RAH
-
Our company is being rebranded and we're to fall in line and change the colour scheme of our web application that's currently used internally and is in the process of being sold externally. Unfortunately, the name of our product and the new colour scheme means there may be a trademarking issue with another company who sound/look similar but whose business is pretty much completely different; to pre-empt any legal issues our sales team have decided to rename the software. The original name was chosen 3 years ago and the codebase/application database is built around it; management want the developers and internal users to start referring to it by it's new name (which they haven't even come up with yet), but that's kinda difficult when classes, methods, tables, stored procedures etc. are prefixed/contain the original name. To the development team it will always be known under it's original moniker. Should we have avoided using the name in the code/database and stuck to generic terms?? Anyone else had a similar problem? Having breathed the code for so long I can't imagine calling it anything different when nothing else is changing.
I'll let future me worry about that!
This is one of the reasons why MS uses city names for their planned new OS. Memphis wasn't going to stay Memphis. Everyone knew it who worked on it. You build toward an internal name and build the things that show things to customers with the ability to show whatever name you eventually will give the product. And those people shouldn't see the internal names anyway. There's no telling when you start on a big project what the world will like/hate for names when the project gets close to shipping. Marketing is supposed to figure out using their own forms of divination what to call the thing when it is ready to go.
_____________________________ Give a man a mug, he drinks for a day. Teach a man to mug... The difference between an ostrich and the average voter is where they stick their heads.
-
Our company is being rebranded and we're to fall in line and change the colour scheme of our web application that's currently used internally and is in the process of being sold externally. Unfortunately, the name of our product and the new colour scheme means there may be a trademarking issue with another company who sound/look similar but whose business is pretty much completely different; to pre-empt any legal issues our sales team have decided to rename the software. The original name was chosen 3 years ago and the codebase/application database is built around it; management want the developers and internal users to start referring to it by it's new name (which they haven't even come up with yet), but that's kinda difficult when classes, methods, tables, stored procedures etc. are prefixed/contain the original name. To the development team it will always be known under it's original moniker. Should we have avoided using the name in the code/database and stuck to generic terms?? Anyone else had a similar problem? Having breathed the code for so long I can't imagine calling it anything different when nothing else is changing.
I'll let future me worry about that!
What I find interesting is that here are us IT types being sensible. We wouldn't dream of spending the company's cash on changing names, prefixes and the like in the codebase. Meanwhile the marketing types are all spending fabulous amounts of cash on new crap that will also add no value to the company (and hiving off the old stationary supplies too, I should think) With naming I generally try to keep generic - but thre are times when you need to use some name, and having a class called "TheProductDataAtapter" doesn't roll off the tongue quite as well, does it :)
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')