Take the 2-minute tour ×

We've all been there - a product feature is called "gold", and then a week before launch they decide it is to be called "platinum". Luckily, you had some nous about you so the UI code is easy to change.

But...what about all the variables and methods? Sure, you could change all these but what about the testing time?

Obviously Resharper or some other enterprise level refactoring tool may help but how do you sell a zero-value proposition to the business? After all, that text change on the front screen is just a 2 minute job - right?

share|improve this question
Not sure I'm getting why you have to change variables and methods for rebranding? –  Amy Blankenship May 3 '13 at 22:46
That is the kicker - you don't. But when some poor SOB comes to maintain the code in 3 years time, he'll see all these references to "gold" everywhere. Whilst throughout the business and in the documentation, it is called "platinum". –  Robbie Dee May 3 '13 at 22:50
Just consider that to be an architectural design lesson for next time :) –  Amy Blankenship May 3 '13 at 22:57
That is a good point. If nothing else, it tracks the train of thought throughout the project's development. –  Robbie Dee May 3 '13 at 23:19

2 Answers 2

In this case I'd use a simple text search to find references to "gold", then use a refactor tool to rename the variables and methods. After that, running the test suite should confirm that there's no issues.

If renaming variables or methods causes issues, you should look at your workflow and find out why it's a problem. If it's very problematic, you could rename the method to the new name, then add a new method under the old name that just passes execution through to the new one, but is marked as deprecated.

Another option would be to add some notes to a general README or wiki, or whatever tool you use for knowledge sharing, and then as people work on different sections, they could rename them piecemeal

share|improve this answer
The branding isn't always so stark. For example, on my latest project, the brand difference was between "best" and "priority". Unfortunately, I also had an unrelated "priority" queue and "best" product selection in my code. +1 for some kind of wiki though... –  Robbie Dee May 3 '13 at 23:14

Don't materialize business plans in code.

Every program that has a real lifecycle will have the problem you're describing. The only way to deal with it is to say "that is not an issue in the code", and to ignore it. Instead of having "gold", "silver", and "bronze" levels and dealing with the rename of "gold" to "platinum" and the insertion of "bismuth" below bronze, have "level 3.0", "level 2.0", and "level 1.0" and change 3.0's name to "platinum" in the metadata (typically in a database) and insert "level 0.9". Or if you prefer integers, count by 1000s - that's plenty of room for insertion and range.

Heck, I once worked on a project where the product name changed so often it was known all through the technical side of the company as "&V2", because that was the substitution symbol we used in the architectural documentation.

share|improve this answer
I suppose if we knew in advance what would change, that would be half the battle... –  Robbie Dee May 7 '13 at 14:07

Your Answer


