Friday, August 03, 2007

Myth #13 - Software engineering managers and triskaidekaphobics, take care!

I am nearing the end of the myth series, but I won't end on 13!
"Internationalization is implemented after the base product and is written by a separate group of engineers."
This one really hurts. And it does take a lot of explaining, but I'll do what I can to condense it. An internationalized product is one that processes data from all over the world. Whatever the product is supposed to do with data, for example, receive and send emails, it can do it with data from lots of different places in lots of different languages using lots of different locale formats. In order for software to be able to do that, every place in the code where the data is touched needs to be internationalized. If the internationalization takes place after the "base" code is written, then that means that a developer is going over the code twice (at least). From a logical standpoint, would you pay development engineers to write the same code twice? That's a very expensive way to develop software. Moreover, would you let engineers who don't have a very thorough knowledge of your code work on the core functionality of your product? That would likely introduce a number of new bugs, some of them quite serious. Yet if you are writing a "base" product and then paying a 3rd party internationalization group to internationalize your code, that's exactly what's happening. And if that internationalized code isn't incorporated into the source tree for the next revision, then you're paying even more to have the same code reworked each time you put out a new version.

'But,' you may wonder, 'my development engineers aren't internationalization experts. How can they write internationalized code?' The answer is training. Internationalization is an aspect of good coding practice. That it isn't yet taught in universities is a real problem, and those of us in the industry are keenly aware of the issue. So you may need to make up for it in house. Set up internationalization training for all development engineers, test engineers, and engineering managers. There are a couple of vendors who provide these services (I don't have firsthand experience with any particular vendor). Furthermore, there is a tremendous amount of documentation in books and online, talking about the concepts as well as the implementation details involved in internationalization. Take a look at the Sun Globalization Resources, and the Java Internationalization site to start with. There are a couple of links on my blog page that have good information on internationalization. Have a look at my article, Internationalization in Software Design, Architecture, and Implementation, and take advantage of some of the mailing lists. In the end, it's much cheaper to train your own engineers than to pay for some other company to rewrite your code. And your engineers may be a little bit more content in their jobs when they're learning new things and have more control over their own code.

Try it out, and let me know how it works.

No comments: