Getting Some Real Offshore Experience
In a former post (see "Offshore Development Woes"), I wrote some personal conclusions from reading Martin Fowler on "Using an Agile Software Process with Offshore Development". It was a summary of what I got from Mr. Fowler's experiences. Interestingly, though I have worked with many developers from many Asian countries over the years, I have never actually worked with an offshore software development company performing development for hire under my direction. It's easy to be an armchair critic.
But that's changed, at least a little. Faced with a recent influx of development projects and a lack of staff to get them done in a timely manner, I decided to develop a relationship with a firm based in India. Being the cautious type I am, our initial foray into this arrangement was for a limited time and scope -- I really wanted to see how well it would work out. And I was especially intrigued given Mr. Fowler's experiences because we too are an agile development shop. I had misgivings based on the rapidity of our development and the time and language differences. But the hourly rates proffered were downright seductive. I figured that at the $25 per hour rate we were being charged, we could afford to lose some time to these difficulties and still come out ahead. And I really want it to work.
It's now been 7 weeks into this trial and I guess I have mixed results to report. First, as Mr. Fowler observed, there is no real cost savings in spite of the seductive hourly rate. Between the language barriers, the time differences, things just plain take longer. A lot longer. And that costs. It's not like the developer in India isn't charging me for those differences. We use email and Skype to get our communication done since written English at least removes accents from the equation. And our developers in India work odd hours, so in spite of the 9.5 hour time difference, I can usually talk to them throughout the morning.
But I've now worked with the group on three development tasks. The initial effort was to get the existing project development infrastructure (Eclipse, Tomcat, CVS, MySQL, and the project code) up and running. I have to say, I was impressed with how quickly and smoothly that happened. It showed that the Indian team was well acquainted with these tools. So we moved on to actual development tasks. I made an effort to be more clear and concise than I usually am in providing task writeups. We had several email exchanges asking for clarification and I got my first code delivery in about a week. I was very disappointed. The code was no where near complete, was undocumented, did not follow style guidelines, and was generally unproffesional (a java package name of "jesus.xml"?). But the real problem was the lack of some basic computer science -- a huge switch construct instead of arrays; a single large method instead of encapsulation, and so on. I rewrote the code and sent it back with further instructions on what I was looking for.
To make a long story short(er), this seems to be the pattern -- delivered code is under-par, I rewrite it and return it, and they then follow my pattern. This put the first several tasks way over budget.
We did make a complaint to the management team. Their solution was to add another resource (a more senior programmer) to the team. At their own cost (to their credit). But now, every detail is being questioned and designed out in advance. We've lost our agile approach. And the costs are higher still, since I spend so much time trying figure out the answers to their questions.
So, in all, this effort has proven to be more costly than we had hoped and it pushed our project costs over budget. It may be that a different team from India could perform better, or that if we developed using a traditional "waterfall" life cycle, things would be better. But this has not been a success for us.
It's now been 7 weeks into this trial and I guess I have mixed results to report. First, as Mr. Fowler observed, there is no real cost savings in spite of the seductive hourly rate. Between the language barriers, the time differences, things just plain take longer. A lot longer. And that costs. It's not like the developer in India isn't charging me for those differences. We use email and Skype to get our communication done since written English at least removes accents from the equation. And our developers in India work odd hours, so in spite of the 9.5 hour time difference, I can usually talk to them throughout the morning.
But I've now worked with the group on three development tasks. The initial effort was to get the existing project development infrastructure (Eclipse, Tomcat, CVS, MySQL, and the project code) up and running. I have to say, I was impressed with how quickly and smoothly that happened. It showed that the Indian team was well acquainted with these tools. So we moved on to actual development tasks. I made an effort to be more clear and concise than I usually am in providing task writeups. We had several email exchanges asking for clarification and I got my first code delivery in about a week. I was very disappointed. The code was no where near complete, was undocumented, did not follow style guidelines, and was generally unproffesional (a java package name of "jesus.xml"?). But the real problem was the lack of some basic computer science -- a huge switch construct instead of arrays; a single large method instead of encapsulation, and so on. I rewrote the code and sent it back with further instructions on what I was looking for.
To make a long story short(er), this seems to be the pattern -- delivered code is under-par, I rewrite it and return it, and they then follow my pattern. This put the first several tasks way over budget.
We did make a complaint to the management team. Their solution was to add another resource (a more senior programmer) to the team. At their own cost (to their credit). But now, every detail is being questioned and designed out in advance. We've lost our agile approach. And the costs are higher still, since I spend so much time trying figure out the answers to their questions.
So, in all, this effort has proven to be more costly than we had hoped and it pushed our project costs over budget. It may be that a different team from India could perform better, or that if we developed using a traditional "waterfall" life cycle, things would be better. But this has not been a success for us.
0 comments:
Post a Comment