Paul Ballard's Weblog

Posts Tagged ‘India’

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.

After just over a year of living in Incredible India, my family and I are only days away from packing everything into boxes and heading home to the United States.  It’s been a wonderful experience made even better by the great friends we’ve made.  We’re going to miss the ex-pat community as well as our native Indian friends.  Okay, we probably won’t miss the multiple daily power outages and the mosquitos but after the swelling goes down and we get used to no longer having to listen for the backup generator to kick on, all of those nuisances will seem as minor as they truly are.

I especially want to thank my teams.  Together we’ve gone from hours spent toiling day and night in a run down office in west London to hours spent toiling day and night in Bangalore.  I know it hasn’t always been fun, but it’s never been boring.  And mostly it’s been a great honor for me to work with all of you and to call you “my teams”.  I hope that you have all learned much but I want to remind you of a few things you’ve heard from me before so that you remember them after I’m gone.

1. You’re better than you think you are.  Make big promises, push yourself.  You never know what you can do until you remove your own limits. 
2. Always do the right thing.  It’s one thing to know what the right thing is, but entirely another to have the strength not to bow to pressure and actually do it.  Don’t let other people push you into doing things you know aren’t right for our systems.  Remember, it always costs less to do it right the first time.
3. Keep learning.  You’ve chosen an exciting industry to work in but it requires that you constantly learn new things.  Don’t let what you do today be the same things you did yesterday.  Your code/tests/designs should improve with every iteration, every release.

Thank you again for all your hard work and best of luck in the future. 

Paul Ballard

One of the benefits of living in a place where you can afford to have a spare room without needing to rent it out to a family of five just to cover your council taxes (yes London, I’m talking about you) is that I have converted a bedroom into a private home office just for me.  I’ve managed to furnish the office with nice simulated hardwood furniture, a custom rug, and various other items entirely of MY choosing.  One of the things I’m most proud of is my awesome new aquarium.

When the aquarium guy came to set up the tank for me he dumped what looked to be about 14 random fish into the water.  They range in size from about 3 inches long to my big Split Tail Barb (The Boss) which is about 8 inches long and a Tiger Oscar (aka Big Oscar or The Bully) that is just a bit smaller.  My first thought was not to bother even naming them as they’d probably all die from being dropped into the tank the first day it was turned on.  But fate smiled on them and with only two exceptions all of the fish have survived okay so far.

However, all is not bubbles and mermaids in aquarium land tonight.  I came home and happened to notice that one of my smaller fish, a shy nerdy one who tends to keep to himself (I call him Mr. ButtUgly, because… well he’s butt ugly), has become the victim of mob violence.  The poor guy was laying in the sand at the bottom of the tank, looking like he was gasping for air (or water?).  To my horror (to say nothing of his), the other fish had EATEN HIS FINS!  His dorsal fin and tail fins are gone! 

At first I wasn’t sure what had happened.  I’ve never had an aquarium so I thought maybe he shed his fins or something.  And while his gasping looked worrisome I recently had another fish (Little Oscar) survive the same sort of thing for nearly 2 weeks after he got so excited about feeding time he leapt right out of the tank and flopped around on the carpet for a while.  So I turned the lights back off and went about my business.  But after just a few minutes I noticed the other fish were circling him menacingly and then biting at his tail while he laid there defenseless and gasping. 

You’ll be happy to know that I immediately intervened on his behalf and pulled him out of harm’s way.  He’s now resting quietly in a private bucket where I will keep a close eye on him for the next few days and see if he can manage to grow back his missing appendages.  I’m hoping I can nurse him back to health and then feed him such that he gets big and bulky so he can go back into the tank and get some well deserved scaly justice!  In the meantime, if you believe in a higher power (Jesus, Buddha, or L. Ron Hubbard – any one will do), pray for little ButtUgly as he tries to work through the trauma of life in… The Aquarium Of Doom!