Paul Ballard's Weblog

Archive for the ‘Outsourcing’ Category

One of the most common issues that western companies deal with after outsourcing software development to India is a lower standard of quality of the software/testing being done.  It would be simplistic, and a little racist, to simply say that Indians are incompetent, incapable, or most laughably – lazy.  I’ve dealt with literally dozens of western managers and developers infuriated by software delivered that functionally works, but that doesn’t follow what we would consider even a modest amount of professional development discipline.  This can include things like no unit tests, unit tests commented out, poor understanding of the technology being used for development, insecure code that would falter under even the slightest SQL injection attack, etc.  Again, the software generally works but is not something you’d want to trust your customer’s credit cards to.

Getting to the real problem

Rather than simply label the developers as incompetent, to be successful you need to understand a bit about the culture to get an understanding of where this problem could be coming from.  Nearly 1/3rd of the world’s poor live in India, with estimates ranging around 645 million people.  That poverty has led to a culture of making the most from everything they have.  Very little is thrown away, and what is thrown out is then picked through and reused again.  That spirit of ingenuity is what has allowed India to start pulling itself up to become a major influence in Asia and the rest of the world.  There are literally dozens of examples of this that you see every day.  From motorcycles turned into trucks for hauling goods to cow manure used as cooking fuel, everything can be used for something. 

But that ingenuity comes with a downside.  When resources are scarce, the mindset is generally to take the shortest solution to any problem.  One of my favorite examples of this mindset shows up in Indian construction.  All over India beautiful new skyscrapers of steel and glass are going up, most of those do so with construction workers crawling on scaffolding made of bamboo sticks lashed together.  Why?  Because bamboo sticks are all that they need.

For your developers, the same mindset leads to software that functionally works but is of poor quality.  Your requirements outline the functionality required but if you don’t make the quality requirements as equally clear then you leave it to them to decide the path they take and more times than not, that path will include bamboo scaffolding and smell of cow poop.

How to to get past “Good Enough”

The key to ensuring the quality of the software delivery is to create processes that enforce proper practices.  Don’t leave quality decisions to the teams until they show that they understand the level of quality you expect as a standard.

1. Make nonfunctional details part of the specification.  This includes unit tests, code coverage, documentation, etc.   Code is not accepted until these items are also met.
2. Use modern development automation to help find issues before testing.  These include continuous integration, automated builds, and automated regression testing.
3. Provide training for all technologies that you expect the teams to be proficient in.  Don’t assume they already know anything more than basic syntax.
4. Code review EVERYTHING!!
5. Find leaders within your teams who understand the quality required and appoint them as mentors to the teams.

Sometimes a cigar is just a cigar

While my interpretation of the cultural mindset of “Good Enough” might explain poor quality standards, this doesn’t mean that there aren’t some bad apples out there.  Not every developer has the drive and discipline required to produce quality software.  Your best bet for those individuals is the same as bad developers in any country.  Minimize their ability to drop bombs into your code base until you can eventually get them off the team and out of your hair.

<Disclaimer> Please see my earlier post for a basic disclaimer and explanation of the intent of these posts.</Disclaimer>