Tad McClellan - Professional Profile

Working with people who are not in your location is a new situation for many people these days. My leadership is in New Jersey along with some other development teams I work with and most of my users are not in Dallas. While most of my users are in India I have a good number in the Caribbean, UK, and in the next couple months Australia and Germany. I work with system administrators in Singapore and Stuttgart. I have to remind people that people all around the world don't get July 4th off. Really there are very few if any "Global" holidays. Christmas is close but not quite. New years seems to be the only one I can think of.

If I had to put one thing on the top of the list of priorities when working in this environment it's communication. You have to make an effort to think about what needs to be communicated and the best way to facilitate that. Meetings are really hard to accommodate as it generally means that someone has to wake up early or stay up late. Email works well except you have to remember that anything that needs to be fixed or communicated probably will take at least a day depending on what time you send it out. Unfortunately people all around the world need to sleep and without exception most of them like to do that at night.

Working with a distributed development team adds some more complexities. Their are 4 pillars of any development organization.

1) Source control (version control)
2) Task Tracking (SDLC tracking)
3) Testing
4) Deployment

These 4 things must work in a distributed environment. We use VSTS which deals with source control well. As far as task tracking and SDLC I find VSTS too project centric. It's difficult to see multiple projects at that same time. We use the AxoSoft product OnTime for this which is much better then VSTS tasking. The downside is that the web version requires IE7 and my company has yet to upgrade from IE6. The latency from India on the client (OnTime is one of the few packages that has multiple interface options) is slow but workable. I prefer fat clients for this type of thing as it is very important that people be able to quickly create screen shots and save them to the task. That really can only be done on a web client if the user saves the file to disk first which is a major pain.

Testing is a topic unto itself as it's the heart and soul of any development group. Let me just say here that any product that is written will get tested, the question is by whom. If their are defects in a production the sooner they are found and the closer to the developer they are found the better both money wise and politically. The best way to deal with testing is continuos integration and automated testing. Those are big topics and with data driven applications very difficult to get done. I'll save our solution for another day. But suffice it to say here that having builds and tests run every 4 hours on a product where check-ins can happen 24 hours a day due to development happening around the world is critical. You want people to know about issues as soon as they happen.

Deployment on a global scale is a development issue since many times the application has to be created to allow for it. Our site has the web site flattened out and then we create the site hierarchy in IIS virtual directories. This allows us to XCOPY deploy. The point of using XCOPY is so we can leverage our DFS/R on our Inetpub directory. This ensures that we have the same version of code on all of our web servers. When you have multiple web servers in multiple locations the last thing you want to do is deploy to each one separately.

TadMcClellan.Com

Global development is a paradigm change for many people. First thing you have to realize is that time is continuous. There are no "off hours". That can make things challenging for financial applications that require off-hour processing to run jobs since there really is not such thing as off hour processing. Weekends are of little help since you have to realize that the Muslim world does not have the same weekend that the west does. The best way around this is to architect applications in such a way that they do not require jobs to work properly. If that cannot be avoided then the application should not require down time when the job is running. I've seen companies make people in India work nights to accommodate their systems down time then wonder why the turn over is high.

Another pitfall of global applications is to make an application that scales in one location. Putting 12 IIS servers on a clustered SQL back-end in the US does not help with 300+ ms latency to the other side of the world. Putting the same site in the Europe simple makes the probably equally bad for people in the US as it is for people in Asia. The best solution is to have multiple datacenters around the world with a global site selector which redirects the user to the web site closest to them. In order to do this one must architect the database to allow for transactional replication. Replication is very useful but you have to know what your doing with it. Replication collisions must be prevented. Also many sites allow for users to upload files to the web site so using DFS/R or some other folder synchronization technology is needed so the file exists on all webservers when its uploaded to one.

No application should be allowed to call itself a global application that doesn't reflect the users culture settings in dates and numbers. This concept is called localization. Even if you don't know an application will become global, you should create an application that uses localization. A much challenging topic though is translation. Not everyone knows English, especially in Asia where the people most likely using a data entry site will not know English. Microsoft has functionality to present a site in multiple languages but I find this solution far from the solvency we need. One issue is that if you present a site in German, you are likely to get German input. Will the people who are processing the input be able to read German? If you use spell checkers on your site, will they deal with foreign language? A better way is to run the site through a translator made to run with HTML. These are pricey and sometimes the translation is a bit quirky but any site serious about being culture compliant should think about this as a better alternative.

TadMcClellan.Com

modified on Tuesday, September 2, 2008 4:31 PM

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Tad McClellan - Professional Profile

Summary

Reputation

Privileges