I'm floored by the irony of Indian startups outsourcing their software development.
In a previous life we outsourced to Indian companies because it saved a lot of money (on paper)[1]. The good ones seemed competent, but they weren't cheap so we didn't use them. The cheap ones we did use (disclaimer: limited experience and observations) were staffed by young, inexperienced engineers. The code I worked with, I would put at second year CompSci level.
Incidentally, coding standards are quite limited in their ability to raise the competence level of software.
One example was the coding standard requirement that the number of global variables was to be minimized. In this particular application, there was only one global variable. Minimized pretty well... until I saw it was a typedefed struct, the struct was huge and had several nested structs in it. Abort Retry [FAIL].
Another example in the same application, there were several (not one, not two, but several) funny looking loops that called a function, passing a bunch of parameters. After puzzling through the code, I realized that the code had failed the McCabe complexity measurement, so they had simply cut out the guts of the loop and made it a called function. That wasn't the worst of it... the icing was that they passed the loop counter as a pointer and side-effect modified it in the called function. Owwwwwwwwww!
[1] My gross observation was that it took 3x longer to get a job done, but we paid the outsource company 1/2 as much as the internal engineers. The way accountants run numbers, the longer it took an outsource company to get the job done, the more they thought the company saved.
Quality, price, speed pick any two.Quality is non-negotiable - as soon as quality slips, everything else slips, too. Better options are Cost, Scope and Schedule (or Features, Price, Speed): http://en.wikipedia.org/wiki/Project_triangle
I agree that often people don't surpass the bar of "good enough". This is usually a result of bad programmers or bad employees, not a result of a company wanting to go too fast.
Going back to my original point, let me give you a real world example. I once worked at a startup doing a web app where there was an elaborate ajax heavy content entry process/forms. The javascript code for this page was an ugly hack, but it worked and was bug free as far as we could tell. The code could have been refactored but we decided not to because no other code on the site depended on this javascript code and it was highly unlikely that we'd need to change that page in the next year. We left it as it was and moved onto adding new features and that was the right choice. We never changed that code, and never needed to, but it wasn't great code. If we'd spent a week refactoring it then we'd have been late with some important feature that wasn't late because we decided to leave the js code as it was.
This is something that I've seen several times, and in every case the people involved severely underestimated the time suck of crappy code. "It's not that bad" often means that the developer is spending 50% or more of their time working around deficiencies.
You ignored all the points in my last comment. Let me be more explicit. Bad code is only an albatross if you have to work with it again. What I'm arguing is that it's usually wiser to leave it as it is until the next time you have to work on it, then fix it. It's only an albatross if you don't fix it, and you only save time by fixing it if you actually have to touch the code again. So wait until you're certain that you're going to have to touch the code again, and fix it when you touch the code again, and not before that.
So why is your supposedly decent programmer writing crappy code and assuming that they'll never have to touch it again?
Which is my original point. Traditionally the expectation is crappy-fast-and-cheap vs. perfect-slow-and-expensive, but that rarely holds. Instead it's usually the crappy code that ends up being slow to write and expensive, stuck in endless code and bugfix cycles trying to get it right.
Wanted to add, for every dollar an Indian firm makes, the average developer gets probably around 8-10 cents or less. When you are at a subsistence level like that, it's difficult to ask questions. You focus on the insecurity instead.
This was something we covered in some detail in our talk at Rubyconf last year. Here's the link FWIW: http://speakerrate.com/talks/5120-india-ruby
When people are told for a couple of generations that they should shut their mouths and look down if they don't want their families hurt. They tend to obey.
My experience was that I was development lead of a project that had development outsourced to a former Yugoslav republic. We had clear agreement (on all levels) that we shall use direct communication on appropriate levels. But what happened in reality was that every memo or inquiry I did - the local development lead would not respond to me directly in a timely fashion. Instead the information would be passed up to the CEO of the company who would then proceed to send this information to my Executive Director who would then send it to me (in an understandably untimely fashion). Needles to say we had to break the effort and search for local developers.
And further east you go more of this effect you see - people refuse to convey information that is clearly in their jurisdiction, because their boss might not agree with everything.
A fucking nightmare.
I actually began writing about it, but then decided I shouldn't generalize about all of Eastern Europe from just my experience.
Management tends to be poor to atrocious, effective management is seriously lacking through all industries there. Add to that resource constraints and competitive pressure you have in outsourcing shops, and it multiplies many-fold.
Many people won't go to them because they are not cheap.
If you spend time in terms of vetting the team for people you are comfortable with, take the time to be as clear and detailed as possible with the requirements, have a good continuous build system so that you can see the software being developed daily, and have direct, continuous communication channels to the coders, one would have a far better experience.
If you're not looking for an overtly complicated project, try hiring undergraduate students. Not from any university though. Try the students IIT's and BITS Pilani. These are the foremost technical institute in the country. So, how do get in contact with them? Visit their Computer Science Association websites, contact their student president to help you out. More often than not, you will find brilliant programming talent this way. Some of them will value a letter of recommendation (that may help in their MS or PhD) very highly.
If not that way, always insist on seeing the portfolio/previous work of the guy you'll be outsourcing too. Else chances are you might end up outsourcing, say a e-commerce implementation, to someone just learnt how to echo in php.