Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

My company is currently at a rebranding process and the brand names have been used in the sources' package names but these names are only visible to developers who maintain this code so nobody from project management is really interested in changing them considering also that it would imply the recompiling of several old components.

What factors do I need to consider when deciding on a change like that?

I don't know if I should worry about legal issues or not and if so, how to address this with project management.


More background details. I have all the sources and dependencies but since the company rebranding, other development areas have adopted some of the code that needs package name-changing so I cannot take the decision only by myself so I don't make everyone else's code to crash with my core components and I cannot change other areas' code without the permission of those areas' users so yes, my concern is more political than technical. I am going try to coordinate the involved it areas to make the change anyway, since it seems to be the best approach.
 
Unfortunatelly in my company there's no continuous integration build server so we build our code manually on demand and to get something to production I have to justify the change (even just the package name changing) to QA with an user requirement and some other bureaucratic documentation so that's why I was hesitating the change in first place.

share|improve this question
add comment

3 Answers

up vote 3 down vote accepted

This is usually a political/marketing question as much as technical. I have been involved in mergers where changing all references to the old name was mandated

Assuming it is just a technical question, are you missing buildable source for any of the components or are there similar significant technical risks? Will making the change break backwards compatibility when backwards compatibility is important? If the answer to either of these questions is "yes", clearly avoid the change.

Otherwise, I would recommend making the change. Changing it is only going to get harder as more development is done and, otherwise, you will need to explain it to every new developer on the project.

share|improve this answer
1  
Actually I have all the sources and dependencies but since the company rebranding, other development areas have adopted some of the code that needs package name-changing so I cannot take the decision olny by myself so I don't make everyone else's code to crash with my core components and I cannot change other areas' code without the permission of those areas' users so yes, my concern is more political than technical. I'll try to coordinate the involved it areas to make the change anyway, since it seems to be the best approach. Thanks for your answer. –  Roberto Linares Aug 30 '12 at 5:38
add comment

How many source files are you talking about? If lots then it starts to become a problem.

But then again, I presume the Grown Ups factored the costs involved when considering the rebranding? Or did they just consider the reprint of letter heads and business cards?

My view (which seems to match the previous commentators) would be to JFDI... perhaps to keep QA happy, raise a standalone change request (or whatever the company parlance is) to do it - in theory this should be a "no executable impact" change - ie the new output should be the same as the old one.

Perhaps also, you should increment the major version, to start as a clean slate?

share|improve this answer
    
Actually for this first phase they only considered the logo/theme changing in the front ends and the source code is about 1000 class files plus XML configuration files so I will take the effort since everybody has recommended it. I just wasn't sure if it was worth it. Thanks for your answer. –  Roberto Linares Aug 31 '12 at 14:02
add comment

While there's no immediate need, eventually as new code gets the new name it's going to become a pain remembering whether something uses the old or the new name. It's a simple fix, so you may as well get it over with. The main reason not to would be if your code was widely shared outside your company. If you control all the source code it's only a minor inconvenience.

As far as having to recompile old components, I'm not quite sure I follow you there. We recompile all our code a few times per day, and consider that to not be often enough. If you're not using a continuous integration build server, it's well worth the investment.

share|improve this answer
1  
Unfortunatelly in my company there's no continuous integration build server so we build our code manually on demand and to get something to production I have to justify the change (even just the package name changing) to QA with an user requirement and some other burochratic documentation so that's why I was hesitating the change in first place but now I think is for the best. Thanks for your answer. –  Roberto Linares Aug 30 '12 at 5:32
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.