Horror stories of offshore development.

If you are working in IT, you may have encountered a programmer from countries like India, China or some East Asian nation. Off-shore development is ubiquitous (if not popular) in US companies. And countries like Australia, New Zealand and Western Europe outsource their IT services and development to other countries as well.

I am in IT industry, myself working as a coder (sr. developer, team lead, architect, consultant, owner of business etc. are just another nice titles that finally ends up making me write code anyway) for last 12 years or so. Everyone working in IT dept, who had to work with an offshore developer has some story to tell and I am sure there are more horror stories than pleasant ones.

Even though I have successfully completed many projects working with offshore team I have come across few cases that I learnt a lesson from.

Year 2000: It was in 2000 that we first time worked with a company in Hyderabad, India. At that time we were working on a VB 6 and Oracle project for a company in health industry. Our team here had no one expert in Oracle and we were told the guys in Hyderabad were the expert. And they will do the VB 6 as well. So after few weeks the first set of code came back and while reviewing we noticed there was a code like:

If (Keypressed = 13) { //do something }

So, my first reaction was to ask them not to use any hard coding like this, and asked them to correct it. And next day the code came back looking like below:

Dim someveriable as int Somevariable = 13 If (Keypressed = Somevariable) { //do something }

This was enough to tell us the guys there did not understand what is ‘hard coding’. And things like this went on. I would write long mails every day pointing out lines of code in VB as well as Oracle PL/SQL  and it went on for few weeks. Finally, we took it over and completely finished ourselves.

Lession Learnt: If you have to educate your team about the simple programming practices then the team will not succeed in the project. I have never seen any IT project where there is enough time for everyone to learn and then deliver. If you have such project, then you got enough money and you are not asked to use offshore team anyway.

Year 2003/2004: This was the beginning of .Net era and Java was already a mature technology. I was assigned to an already developed project as a mediator between US users and Indian development team. The project was developed in VB and classic ASP. And the users were US sales team. We tried to install and release the software for the US team but they would not use it. So, I made a whole big list of issues why they were not using it and got the Indian team to fix those issues. Everyday, I would spend writing big emails and few hours talking over the phone early morning.  Team in India would work late nights and get those issues resolved.

But after all the effort, US team never used the software. The company was able to sell it in other Asian countries but not to their own team in US.

There were some positive things in this story:

• The development team was technically sound and they had their own technical architect, designer etc.
• They looked at some industry leading software (like SAP) to create similar functionality
• Turn-around time was reasonable

But

• Sales team had probably seen better software in US market and were thinking that this was a cheaper model; so they were not inclined to use it
• Software did not integrate with Outlook Calendar or Contact List so it did not provide any natural benefit to the team; it was one more thing to maintain in their daily routine of work
• The company was making investment in older technology like ASP while new ASP.net was already getting popular.
• Development team tried to use some code base from other software that they had developed; and that introduced many limitations.

Year 2008: One of my clients had got his project developed in India in .Net using Telerik controls. But the application would work so slow that it would be impossible to use it. He asked if we would be able to refactor or rewrite it.

And when we looked at the code, we noticed the whole application was one single ASPX page having different Panels in it getting visible or hidden. So, all the different screens in the UI were in different panels and they were displayed or hidden based on what menu item was clicked. This made the ViewState huge and of course the application was unusable.

We had to rewrite the application using AJAX.

Year 2010/2011: One of my clients outsourced their project to a US based IT company. And this company is a publicly traded billion dollar company. So you may think what could go wrong. Well, everything went wrong – and at the core of it were one non-technical decision and one technical decision. Non-technical issue was, they tried to achieve too many things in one shot instead of creating a solid base and then evolving on it. Technical issue was the software did not support database transaction.

But the story did not end there – that was the beginning. Now, the client turned to an offshore company in Delhi, India. They hired almost 12 developers there making 2 of them technical leads cum designers and rest of them developers or senior developers.

We here in US were also termed as design leads and asked to guide the team in India. But the team leads in India probably did not like that and conflicts started. They thought their contribution to the project is more ‘technical’ and they did not care about the ‘business’.

Non-technical:

• We used Skype, but the programmers would not stay on Skype during our morning times and will be away.
• They did not give us their phone numbers, neither desk numbers, nor cell number (until last month of project) so we could not call them. We had to email them asking to call us.
• They would have to reserve a room to talk to us, so if that room was booked by any other team then they would not be able to talk to us.
• We found that some other programmers were working on the project using assigned people’s Login Id. That means the programmers that we hired were being used for some other project.
• I would request a meeting and get up early morning 6 AM to attend it and at 6 AM they would not show up and ask to postpone for another day.
• People would be out on lunch around 3 or 4 PM Indian time.

Technical:

• We wanted to follow MVP pattern in the WinForms project but all the code would be in View file and nothing in the presenter. Also, presenter was coded more like a model to get the data from database and that’s all.
• A framework library was created but it had 10 to 12 different folders and different namespaces making it hard to use the framework classes.
• WCF was used but it would hide all the error details and they could not understand in what cases the WCF should hide the exceptions and in what case it can expose it. This made it hard on the client side to find out the cause of the error or to check the stack trace.
• Even though we had business objects and custom collections, developers used standard System.Data’s DataSet and DataTables to retrieve the data. The real object-oriented programming was either ignored or forgotten.
• Similarly, to save the data, all data was stored in custom XML and saved instead of using objects and custom collection. This made it harder to debug the issues or even make modifications.
• Programmers would write catch(Exception ex) { throw ex; } type of exception handling. Beat That J

We again ended up taking over most of the development. We also stopped assigning issues and fixed them on our own. Though they helped fixing some issues it was always taking longer to communicate than to do it ourselves.

Other Cases:

• You might run into a company who would charge you less for the project you want done and then increase its price later on when it may be too late. If the increase is up to 10% you can bear it, but I had a company who wanted 33% raise and I could not tolerate that.

• ‘Hours’ is another important thing that may raise eyebrows. One of the companies I worked with reported 100 hours for the work done. I was okay with that and asked him to invoice with the agreed hourly rate. Then they realized they were getting less than expected amount. So they reported it took them 200 hours but by mistake they reported 100 hours.

Conclusion:

We are still using offshore resources for some of our projects but we select the type of work that we want to send to offshore team and the type of project where their contribution will be worthwhile. After all these experience we don’t write it off. But many companies do this blindly. They think using offshore model is like buying a new TV or Laptop from a Thanksgiving deal. You can’t rush and get the deal because everyone else is getting it.