Changing company name...do we change namespaces?

Question

We plan on changing our company name sometime soon. All of our namespaces, projects etc use XYZ.ComponentName.

My question to you would be should we change our namespaces? Change all the old components to ABC.ComponentName? Leave the old ones but any new development becomes ABC.ComponentName? Just stick with the old name?

Answer 1

It Depends.

Some things to consider: If changing the namespace means moving files in CVS, then there is a penalty because you lose the history. If changing the namespace means manual work, you're going to miss places and cause bugs.

Also, do you have external users of the code/libraries? If they have to change their code because you've renamed the company, they will be annoyed.

I'd be inclined to leave the code the way it is. Namespaces are meaningless except to prevent collisions; at this point it's only marketing. But for new products I'd for sure use a new namesapce.

Where I used to work we had a few company-name or app-name changes and it was always problematic. One application was delayed by a couple weeks while they ironed out the bugs from a global namespace change at the last minute. Another application never adopted the new names and was always internally referred-to by the obsolete name, potentially confusing for new users. Imagine if everything in Java was still called 'Oak'.

Answer 2

Are you selling those components to 3rd parties? If not, then it's not worth the effort. If you are, then the namespace is part of your marketing and therefore should be changed.

Answer 3

As for the current pickle you find yourself in, I would ask for some $$ from the signage changing budget for fixing the code. If they don't give it to you, leave the old name be.

I think the proper answer is that you don't create namespaces with your company name in them in the first place. Pretty much everyone there knows who signs their paychecks; you alliviate no confusion by enshrining the name in code.

I had one coworker who discovered namespaces one day, and next thing I knew our entire software library has to be accessed through several layers of namespaces designating our company, division, and project. The thing is, we only really have the one project (although you could convince me of the benifit of that), the other divisions don't do software, and code we take from other companies doesn't follow his scheme. So really its just a lot of useless extra typing we have to do. Yes, we can do "using", but then there's no real benifit to the namespaces at all. Oh, and of course our division name changed a couple years later, when management decided "division" sounded to devisive, and we should now be called "teams". %-(

Namespaces are really best used whenever you have several classes which you would be tempted to name startimg with (or including somewhere) the same string. They aren't for mirroring your software development group's current management reporting structure.