2014 Development , Information Technology , IT , Off-shore , Off-Shoring , Out-Source , Out-Sourcing , Programming , Small business , Software 0 Comments

This is a topic that I have dealt with on a first hand basis. My experiences with off-shoring and my general dislike of the practice stem from my intimate interaction with the process. I will not say that ALL off-shoring agencies will have ALL of these issues. What I will say is, not in a million years would I suggest a company take this avenue.

The drawbacks I am referring to were actually a series of smaller issues that piled on top of each other, and that lead to disaster.

Communication

At first, it was minor communication issues between us and the offshore development team. As good as requirements can be, there will always be questions or clarifications from Development to Business. To communicate with us, the process they had in place was for the development team to communicate through their Project Manager (who was in our time zone), and the PM would talk with us. This cycle took a full day in most cases (due to the time zone issue). A few questions lead to additional questions, and this resulting in some issues taking up to a week to be fully answered. To address this, the development team began working during our work time. As an unintended consequence, the Team Lead (who was female) didn't feel safe enough to leave the office at night, so she slept at the office during the week.

Attrition

At almost the halfway point to the project (about 5 months in), we began to notice significant issues with quality, and deliverables not being met. It took us a while to get to the bottom of it, but what had happened was a few senior developers had left the company (one of which was from our project). What the company did was move one senior developer off our project, and put them on another (to cover that project). That left our project without 2 senior developers. As part of the contract, we were to have those senior developers, so their company promoted two junior developers to senior to cover them contractually. They then hired two entry-level developers for our project, and called them junior developers.

Quality

We were left with one Team Lead, one senior developer, and 6 junior / entry-level developers. Not surprisingly, the quality of the application suffered greatly. Defects we could handle, but it was the lack of experience in coding that lead to significant PERFORMANCE problems. Our application was expected to handle a large amount of data in real-time, and due to the way the application was built, it would not perform anywhere near the pre-defined requirements. What followed was attempts to refactor areas of the application, and - although performance improved - that refactoring was not able to meet our performance requirements (or that of our End Users). As a last-ditch effort, some areas of the application were re-written, but it was too late.

To be fair, I believe the re-written pieces of the application would have met our performance criteria.

Outcome

With the communication issues, and lack of experienced developers, the project had significant quality and performance issues. The delivery date (for us and our client) was missed, and the make-up date was also missed. With the state the application was in, combined with an uncertainty of completion date, our client pulled the plug on the project.

What ended up happening was we lost the client, the client sued the company I worked for, the company I worked for sued the offshore development company, and the two people in our company who recommended off-shoring lost their jobs.

Conclusion

When looking for a Software Vendor, ask yourself if the benefit (which is ONLY cost) is really worth the risks and drawbacks, and potentially negative outcomes (which are many).

What I can say is that due to my experiences with Off-shoring software development, there is no power on earth that would make me go that route; the stakes are just too high to gamble.

Randy May
DevOps Specialist | Agile Architect | Sr. Software Engineer
Blaazin Software Consulting Inc.

Since beginning his career in 1999, Randy has become a seasoned and accomplished professional in all areas of Software Development. He honed his development skills at several development organizations, and has embraced a focus on software quality and the speed of development. He has implemented processes and technologies at many software companies to reduce time-to-market, and improve overall quality.
Email: randy.may@blaazinsoftware.com
Website: www.blaazinsoftware.com