In startups, there's an unspoken rule that says that Marketing gets to change the product name up until the day the product ships. And they often do. Or if they don't the company changes its name or logo (often after engaging an expensive "image" consulting firm). I ran out of fingers when counting the times this has happened to projects I've been on.

To defend yourself against the chaos this inevitability can cause, follow these steps:

  • Use a consistent copyright in your source code. A consistent string is easy to change via a regex. To ensure that you're being consistent, write another script that periodically spiders your codebase looking for errant copyrights. If you're unclear about the importance of correct copyrights, ask your corporate lawyer, or someone in business development.

  • Avoid hard-coding either the product or the company name. Where possible, use resource files, or the platform equivalent, rather than embedding product or company names in strings.

  • Avoid hard-coding colors. If the corporate logo changes, there's usually a downstream change or two wherever the logo appears. Or, if you're really lucky, Marketing will engage the services of a usability guru, who will issue his report on Wednesday of the week the product ships, and you'll need to change a bunch of colors (at least). If you're using templates, put colors in a common style sheet.

  • If you're responsible for documentation that'll be visible externally, and are using a document editing tool that supports variables, use them for both the product name and the company name. This'll save you a lot of search and replace time.

If you work it right, you can accommodate company or name changes within a few hours, plus build time. If you don't work it right, you and the team have a very long evening ahead of you, probably while you're already in crunch mode.

  • Comment on Planning ahead for product name changes

Replies are listed 'Best First'.
Re: Planning ahead for product name changes
by footpad (Abbot) on Sep 25, 2002 at 13:08 UTC

    Actually, Tadman brings up a good point, for the techniques that allow for rapid and flexible localization can greatly assist visual re-branding efforts as well. After all, if your logo is a resource and it changes, well, change the resource and you're done.

    I've previously mentioned that I used to work for a commercial software vendor. Everything sold locally was translated into multiple languages and character sets. This was frequently a difficult task for the International team and they spent significant time and energy trying to teach the U.S.-based teams how to best make the localization process as painless as possible. Here's a set of guidelines (slightly amended with additional notes from my experience) they once distributed in the form of bookmarks:1

    • Character Sets:

      Use relevant API's and locale aware libraries for character manipulation and classification when appropriate. (Note: this should include specifying character encoding whenever possible.) Remember that there may be differences between the end-user's machine/environment, the operating system running the program, and the server handling the data.

      This may include issues like character conversion (and loss), alternate sorting patterns, the direction of text, and extended characters.

    • Data Formats (Numeric, Date, Currency):

      Be prepared to support alternate separators, symbols, and formats. Also, be aware that "standard" data arrangement may change from country to country. Example: Placement of the country in an address block, as well as the name of the postal/routing code.

    • Expansion for Translation:

      Allow room for expansion, especially in displayed strings and buffer sizes. Use dynamically resized buffers whenever possible. Add overflow, underflow, and overrun checks.

    • Core International Tests:

      Include a core set of internationally-enabled tests in core QA. (Meaning, don't always perform unit testing with straight ASCII/ANSI/UTF-8. Make sure automated tests include alternate character sets, different data formats, and localized strings--including characters unique to the alternate character sets.)

    • Separate Resource Libraries:

      Use separate resource-only libraries (modules or DLL's, depending on the environment) for all translatable components, including text, coordinates, and font definitions. (Note: this should also include any image data, such as colors and graphics (JPG's, GIF's, or BMP's).

      Also, remember that different cultures respond differently to abstract images differently. Simple example: Stop signs. Colors mean different things to different cultures.

    • No Dynamic Concatenation:

      Sentence structure changes internationally. Use string formatting functions, replaceable parameters, and lookup tables.

    • Duplicate Resourced Keywords:

      Allow for the use of either English or localized keywords; let the user choose.

    Now, yes, this was originally developed by a company that worked with Windows and DOS based operating systems; however, the same issues apply to Perl CGI scripts, HTML, and (AFAIK) just about any other technical production environment that might cross borders.

    Also, name changes and re-branding efforts aren't limited to start-ups, you know. I've seen them happen in:

    • Established companies: The last company I worked for had been purchased by another just before I started. Eventually, the new owners decided to "rebrand" all the products produced by their subsidiaries to incorporate their company name. This included logo changes. Since I was working on financial calculation software, it meant extensive changes throughout the product, including bitmap changes, textual changes on the GUI, report modifications, Help file updates, installation modifications (including supporting utilities), and so on.

      (Naturally, the new owner was in turn bought by a third-company about six months after we finally managed to get everything rebranded--and the software retrofitted to support future changes. Guess what the new owners wanted?)

    • Commercial software: Many companies in this segment use code names for their products up until the final build. It may eventually ship as Uber Widgit Deluxe, but until marketing can obtain a trademark (which can be a long, arduous process), you have to refer to it as "Foo." As you might expect, this affects information displayed to the user, supporting documentation (whether source for printed manuals or POD), and a number of other items.

    • Consultancies: Many consultancies develop shared libraries and application frameworks to help them develop software more quickly. This lets them reuse many elements with different clients. However, you have to be careful developing these, for it can take as long to "convert" AlphaCorp's contact management database for BetaBiz.

      On the flip side, a properly designed framework can make this conversion effort a breeze. In my experience, frameworks designed with international issues in mind tend to be easier to visually re-brand than those developed with a single set of idioms and standards.

    (I'm sure there are many other cases; these are just the ones I've run into during my career.)

    In short, planning can make a tremendous amount of difference in many areas.



    1 - By bookmark, I mean a small piece of laminated paper one uses to mark one's location in a paper book, not those virtual shortcuts one stores in their browser to flag interesting (or plain wierd) sites on the 'Net.

Re: Planning ahead for product name changes
by tadman (Prior) on Sep 25, 2002 at 09:55 UTC
    The other things many programmers dread is when they're asked to perform I18N. Internationalization.

    I'm astounded by how much text, usually English, typically appears in code. The most common is seldom issued error messages that are, for whatever reason, presented to the end user.

    The one thing you can do is just make a look-up table for text, a sort of linguistic style sheet. This can be translated in its entirety when the time comes, instead of having to dig up every bit and piece in a panic when marketing announces they're moving into the European market. Next month.

    A simple thing if you plan in advance, but very difficult if you do it in the end. Now as for the language in URLs, that's an entirely seperate argument.
      I'm astounded by how much text, usually English, typically appears in code. The most common is seldom issued error messages that are, for whatever reason, presented to the end user.

      I started noticing the same thing in my own code and specifically wrote an object class to let me centralize the management of error and similar messages, including ones containing run-time content, like this:
        print $error_messages->file_open_failed($input_file);

      You don't actually have to define a file_open_failed object method; that's syntactic sugar that AUTOLOAD turns into the conceptual equivalent of print $error_messages->construct_message('file_open_failed', 'myfile');.

      In my case the issue wasn't I18N as much as wanting to have consistent messages across a sprawling code base, and keep them in a single place for easier documentation -- but the basic issue is not dissimilar.

      I've made the module available here; sorry for the off-site link, but I haven't yet gotten around to CPANning it. Feedback is welcomed!

      As for things like the name of a program, I sometimes consider that a candidate for use constant..., though unfortunately that doesn't help if you need to change the name in documentation and other collateral. Even macro expansion or search-and-replace isn't perfect, because if you're not careful your documentation may contain phrases like "a FooBar report may contain Bazzes", which after transforming, say, {FooBar => AlphaBar and Baz => Blarg} can become something rather convoluted like "a AlphaBar report may contain Blargzes".