Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why India outsourcing is doomed

devbattles.com

Post reply on HN
Print view View original

81–90 of 91 posts

Re: Why India outsourcing is doomed

#81

Post by kamaal »

curiousDog wrote: post #24

Oh not this stupid argument again. Many problems he mentions aren't specific to India, you'll find them across all developing economies (We had most of the same issues contracting work to a Chinese and Brazilian company). At the end of the day, you get what you pay for. And some companies are clearly okay with said cheap work. There's a reason the IT industry in Hyderabad/B'lore is booming. Want solid contracting wor…

>>The reason you're outsourcing core-work/parts of it to India should be that you can't find enough talent locally

Sometimes, but not always. A lot of companies outsource because they feel software is just not a part of their core business. Very similar to the way why some companies outsource payroll.

Re: Why India outsourcing is doomed

#82

Post by webtopaz »

I have worked in outsourced projects for a big company in the past and our team got the work done. I have since then started my own company and have been working for US customers from India. My current customer is a startup from Philly for which I have been working for about 3.5 years. So, No. Indian outsourcing is not doomed. There are thousands of small companies like mine making customers happy at an affordable price.

And what's with the pictures of a snake charmer and a crowded jeep?

Re: Why India outsourcing is doomed

#83

Post by archlight »

curiousDog wrote: post #24

Oh not this stupid argument again. Many problems he mentions aren't specific to India, you'll find them across all developing economies (We had most of the same issues contracting work to a Chinese and Brazilian company). At the end of the day, you get what you pay for. And some companies are clearly okay with said cheap work. There's a reason the IT industry in Hyderabad/B'lore is booming. Want solid contracting wor…

this problem is specific to India because India is center of IT outsourcing and this problem is unique to IT. Contracting work to China is mainly manufacture sector which real product are being shipped. quality and standard are well defined in advance. customer can simply reject goods if they don't pass quality test. can you do that in software outsourcing? when we talk about this problem we don't need to mention other contribution done by Indian developers. Let's just focus on one problem. I am sure there is thread for discussing Indian contribution in software industry. Actually author kindly mentioned he also met some very good developers both in US and India to be politically correct.

Re: Why India outsourcing is doomed

#84

Post by collyw »

nailer wrote: post #50
r0h1n wrote: post #43

Take away the point about the 12-hour difference, and you can repurpose this article into: Why Silicon Valley startups are doomed. -Resource Availability -Resource Quality - Employee turnover - Mindset and work ethics - Cost A truly lazy piece of writing about generic/cylical demand-supply challenges that most booming industries end up facing.

Referring to people as resources is normally reserved for Outlook resources at financial institutions.

Most companies above a certain size have a human resources department.

Re: Why India outsourcing is doomed

#85

Post by collyw »

fsloth wrote: post #49
lifeisstillgood wrote: post #34

Earlier quoted context omitted.

Yes, more and better work can be done by less people - it's axiomatic in software. It just takes longer - and often looks like people sitting around thinking and experimenting.

I agree except for "It just takes longer" Which depends a lot on everything. As an extreme example a bunch of junior people might develop a feature for a few sprints using TDD, XP and whatnot and not getting it done while a single expert might implement the feature simply and elegantly in a few days and a lot less code. My favorite example of this are two blog artifacts: The first of which describes an attempt to wri…

As someone who hasn't really managed to get into TDD (despite a few attempts), do you think this is generally the case? I do feel that TDD encourages a sort of shotgun approach to development, where you just try things until it works, rather than think the problem through thoroughly. Any opinions from people who have done both? I personally find fiddling with tests interrupts my flow of thought too much, so I would rather do it at the end.

Re: Why India outsourcing is doomed

#86

Post by lifeisstillgood »

collyw wrote: post #85
fsloth wrote: post #49

Earlier quoted context omitted.

I agree except for "It just takes longer" Which depends a lot on everything. As an extreme example a bunch of junior people might develop a feature for a few sprints using TDD, XP and whatnot and not getting it done while a single expert might implement the feature simply and elegantly in a few days and a lot less code. My favorite example of this are two blog artifacts: The first of which describes an attempt to wri…

As someone who hasn't really managed to get into TDD (despite a few attempts), do you think this is generally the case? I do feel that TDD encourages a sort of shotgun approach to development, where you just try things until it works, rather than think the problem through thoroughly. Any opinions from people who have done both? I personally find fiddling with tests interrupts my flow of thought too much, so I would r…

I call this the rewrite fallacy. I honestly cannot think of a decent piece of work that I did that did not involve two three or a dozen rewrites - either from scratch (rare) or just piecemeal replacements until I reached a design I was happy with, that fit my domain and was appropriate.

Sometimes the rewrites were on the same project, sometimes the rewrites were on previous projects and I jus looked like a genius coming in to do something I had already done before , but I am always surprised if I can get things right first time (right enough is a professionals baseline, but actually right? Hardly ever).

So, no, I honestly think that thinking through a design, working out and testing out ideas and architectures is a necessary part of development - call it discovery, call it the first iteration, call it perfectionism, it's needed.

Tests should come as part of that. Slowly as you realise the approach you are choosin might actually be the right one and then increasingly as you fill out the space.

Re: Why India outsourcing is doomed

#87

Post by fsloth »

collyw wrote: post #85
fsloth wrote: post #49

Earlier quoted context omitted.

I agree except for "It just takes longer" Which depends a lot on everything. As an extreme example a bunch of junior people might develop a feature for a few sprints using TDD, XP and whatnot and not getting it done while a single expert might implement the feature simply and elegantly in a few days and a lot less code. My favorite example of this are two blog artifacts: The first of which describes an attempt to wri…

As someone who hasn't really managed to get into TDD (despite a few attempts), do you think this is generally the case? I do feel that TDD encourages a sort of shotgun approach to development, where you just try things until it works, rather than think the problem through thoroughly. Any opinions from people who have done both? I personally find fiddling with tests interrupts my flow of thought too much, so I would r…

Boy, are we diverging :)

From my experience TDD is kinda newspeak in the sense that it does not help at least in the first stages of design. From what I've managed to gleam as valuable way of working is test driven implementation. I.e. when implementing something akin to a simple datastructure I can test the interface functions as I write them which verifies the interface is not silly and that it works.

Another place where implementing tests concurrently brings value is using the tests as a form of documentation.

I would not call TDD a design methodology beyond the fact that usually implementing interfaces (and verifying it works) is good practice while speccing it.

Tests bring lots of value to a codebase beyond the fact that it sounds impressive to have a 95% coverage. From what I understand of the pathologies of software development having the TDD tagged as methodology is to allow the programmers implement tests in peace, politically shielded from the more gung ho elements of the stakeholderkin.

Summary: IMO if production code has no tests something is wrong. But I would say the most value tests bring is in verifying the algebra of the interface, protecting against breaking commits and documenting the inteded usage through examples. I would not say writing unit tests is a particularly powerfull design methodology but playing with code is, and calling what the developer is doing as 'TDD' gives the developer the mental piece to do exactly this.

Re: Why India outsourcing is doomed

#88

Post by nailer »

collyw wrote: post #84
nailer wrote: post #50

Earlier quoted context omitted.

Referring to people as resources is normally reserved for Outlook resources at financial institutions.

Most companies above a certain size have a human resources department.

Sure, but that's because most companies above a certain size are old, and department names are the last to change. Younger companies have 'people and culture' or similar.
Post reply on HN