Paul Ballard's Weblog

Posts Tagged ‘Outsourcing’

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>

I’m about to publish a new article/blog series on my experiences as a manager outsourcing software development to India as well as living and working there.  I meant to do this while I was there, but the pressures of getting software out the door coupled with dealing with the issues I’m now going to write about kept me busier than I would have imagined.  So now that I’m back in the USA with power that doesn’t go off several times per day, I’m going to spend some time documenting what I learned in hope that it might help other western managers faced with similar situations.

Setting the stage

In order to understand the viewpoints I’m going to express, it’s worth taking a couple of paragraphs to describe where I started this journey.  I have more than 20 years of experience developing software.  In that time, I’ve held a number of different roles and have worked in every conceivable type of team and industry.  I’ve had projects where I was the only developer and I’ve worked on projects that had literally dozens.  As the industry has evolved, a major paradigm shift occurred as companies looked to commoditize software development and inevitably went searching for cheaper resources.  India and their large systems integrators answered that call and so for the past decade or so, you would be hard pressed to find a significant development team without a native born Indian on it.  In my recent positions I have been a manager of both onshore and offshore native Indian resources, as well as American, English, French, and various other countries.  But the largest majority has been from India.

Here in the USA, there’s been no small amount of controversy over this paradigm shift.  Whether your personal views fall on the side of expanding global markets or nationalist job protection, there is ample evidence available both for and against your views.  In my personal history I’ve been booted from a project and replaced by three offshore resources due to a corporate mandate to move half of all development offshore.  I’ve also staffed projects through my consulting company using offshore resources that were being abused by their management and who refused to let me help for fear of being sent back to India.  And I’ve met more than a few happy, successful Indian natives who after working in the USA long enough to get their greencard eventually went back home to India to be with their family.  But no matter what the situation, the undeniable fact is that the software industry has tied itself inextricably to India.  So as a manager it only makes sense to try to understand software development in this new model, hence these articles.

Disclaimer

While it is useful as a tool to speak of the cultural, work, and management aspects of outsourced software development (specifically in India) in sweeping generalities, please know that I do so with the complete understanding that these descriptions won’t describe every person in/from India.  Each person is an individual and I have had the great pleasure of working with some of the best talent in India.  So as those friends read these posts please remember, I’m not necessarily describing them.  On the other hand, when taken in large numbers the generalizations I will describe are accurate in my perception, if not intent or reality.  I welcome any of my colleagues to correct me if I’ve misinterpreted something in these articles.