Hacker News Reader

Comment by skynetv2 | Hacker News Reader

> shift your development work to under qualified developers or programmers.

How do you justify this blanket statement?

How do you justify this blanket statement?

Because talented engineers don't want to work on the typical things that get outsourced, such as maintenance of legacy applications, helpdesks, implementation of dull ERP projects and so on. Therefore on average the quality of programmer at an outsourcing company is lower than at a real product company, and this would be the same at any outsourcing company in any country. It just so happens that some locations are cheap enough to make hiring large numbers of low quality engineers seem more attractive than fewer, high quality engineers payed sufficient salaries to attract them.

> Because talented engineers don't want to work on the typical things that get outsourced

another assumption without substantiating evidence.

See the comment from @pavanred for some context.

Okay... what do talented programmers like to work on?

If the front-page is any indication, the latest JS framework.

Hahaha... Why do you need talent to work in JS?

I have been a close observer of code coming from India. I think the majority of the problems are because of vague, incomplete, and wrong requirements coming from the company that hired them. One company sent over someone. The guy spent a month talking to management, employees, probably the janitor and figured out what we actually wanted and the resulting code was decent.

This is part of the problem, and, in fact, part of the work of a software developer: given ambiguous and stupid requirements, you work with the customer to 1) make them clearer and 2) get rid of the unnecessary, complex requirements that do not bring any bussiness value. (My experience here shows though that it's not a standard thing in Indian culture to question the status quo).

There's a lot of implicit requirements that need to be taken into account when writing code: maintainability, security, performance, user experience, accessibility etc. It's better if everything is explicitly stated, but we don't live in a perfect world unfortunately. (My experience here shows that those implicit requirements are often not well executed, particularly when it comes to front-end code, due to a mix of: lacking experience, time pressure, different UX sensibilities).

Obviously, YMMV.

Maybe it was just the firm I worked with, but they got the same requirements doc that the software was eventually written against using an American outsource firm.

The Indian firm wanted requirements so detailed that I had to tell them where to put the for loops and while loops. It was faster to just write the code myself than explain such easy details.

Same experience here

That is the problem with outsourcing in general: much of the work a development team do is figure out what the problem really is and how to solve it. The actual coding part is easy in comparison. But the business people didn't really see this, and....well...the results were predictable.

Exactly..

If a spec isn't vague, incomplete and wrong then you could just make a compiler that compiled the spec into working code and skip the programmer.

The job of a programmer is to map the vague notion of what the software should do, which is reflected in the spec, into a concrete, internally consistent set of instructions to the computer.

Not the OP but I can likely offer some insight as someone who has had to deal with teams in India: The biggest problem was the employee turnaround rate. Getting a developer, even an experienced one to become fully productive in your organization if you have several or complex products is a process that can take over a year but the turnaround rate was high enough that there we needed to use a very significant amount of resources dedicated to training and keeping communication and quality flowing smoothly because having people who weren't veteran enough to be able to handle themselves and figure out the business case behind the task and user story was a constant state.

I haven't dealt with IBM, but I have been in charge of outsourcing before. Early on we used Indians, but it became expensive so we moved on to the Philippines. Both had the issue you're describing. If you found someone good they would be gone in a few months for more money. I remember arguing with management above me because I wanted to pay a person 40k instead of 35k (I think those were the numbers, it's been awhile) because he was good, and communicated well (another issue). I was overruled and as soon as this person became proficient, and presumably found a better paying job he never showed up again.

Eventually I convinced management that even if we had to pay 2-3x for a competent developer stateside, it was worth the money because of the hidden costs of trying to outsource. The work we were doing required someone to be invested in learning the business and the problems we were trying to solve.

I think any competent underpaid developer would eventually move on.

Of course. The point was that outsourcing was 'supposed to be cheap'. The reality is that for many situations it is not cheap, and is less expensive in the long run to pay a dev 100k or whatever the local market rate is instead.

The outsourced guy would eventually figure out that he is been paid way less for more or less same work. so they would move to better paying job. You would need to find a amount which is cheaper then US but way more then local market.

Because I've worked with outsourced IBM tech.

Reply on news.ycombinator.com