DISQUS

DISQUS Hello! /var/log/mind is using DISQUS, a powerful comment system, to manage its comments. Learn more.

Community Page

/var/log/mind

Dhananjay Nene’s free (as in free speech) opinions on all things related to Software Engineering
Jump to original thread »
Author

Outsourcing does not suck. Our understanding of it does !

Started by Dhananjay Nene · 11 months ago

This is not a post in defense of outsourcing. However every so often I come across a rant like Why Outsourcing Sucks and much as I emotionally connect to such posts which talk about poor software quality, I find the rant and the underlying thoughts a highly misguided exercise. This post attempts t ... Continue reading »

13 comments

  • Thanks for giving the valuable information.
    Will continue reading this blog.
  • Thanks Niyaz.

    Hope this might have projected outsourcing from a different angle.

    Dhananjay
  • "Outsourcing" is not really single phenomenon that can be given a blanket "sucks" or "rules" rating. Rather it is an umbrella term that actually encompasses a whole bunch of different ways in which a business in a "rich" location can leverage the cost differential between them and a "poor" location. There are many different models of engagement, and each will give you a different result. See for example the experience of New York based social|median and Pune-based True Sparrow Systems - they are extremely happy with their situation.

    Saying "outsourcing" sucks is akin to saying, "software companies suck". The statement makes no sense - are you talking about Microsoft, or Apple, or Infosys, or HSBC software, or Xerox PARC, or AirTight networks, or the small budding startups in Pune?

    Some models of outsourcing suck.
    Some models are great.
    And there is no reason to simplify it by attaching a single label.
  • @punetech

    Not sure if your comment is directed at this post or the one it was referring to. I have actually not attached a label to outsourcing .. instead have explored the economic dynamics around it and the fact that it is perhaps not such a well understood process and it is our understanding of it that sometimes sucks (ie. it is often so casually maligned).
  • You are right. My comment was directed at the post that you referred to.

    I did want to point out the fact that there are different models of engagement. This issue is a little orthogonal to your analysis. I meant it as something else to think about, in addition to what you said.

    How the outsourcer and outsourcee interact makes a huge difference to the final outcome.

    Do you send over detailed specs and just want them implemented, or do you send over a high level concept and outsource the architectural thinking too? Or do you also involve the outsourcee in roadmap evolution details?

    What is the incentive structure in place? Bonus for delivery on deadline? By number of bugs fixed? At the other end of the spectrum is that the outsourcee has equity in the outsourcer!

    Which side of Venkat's Impossibility Triangle are you playing in?

    What are you really looking for? Junior programmers who can learn on the job? Or experienced and/or the best of the best? Like.com was looking for the latter and decided that in this case the cost advantage that India had was not enough to overcome the overheads.

    If you were setting up a local (non-outsourced) team, you wouldn't evaluate it purely on economic terms. You would be worrying about all the above factors, and more. And the success of your team would depend upon which point you chose on each of those spectrums. Same is true of outsourcing too.

    The different ways of outsourcing are different points (or technically, clusters of points) in a multi-dimensional space. Treating them all alike is over-simplification - good for headlines ("Outsourcing sucks"), but bad for understanding them and making best use of them. I guess, I am just elaborating another way in which "Outsourcing does not suck. Our understanding of it does."
  • Wow, great and very in depth post.

    There have been a deluge of posts and rants about outsourcing recently. While I agree that there are some genuine reasons for it having a bad reputation, there are some great freelancers and outsourcing companies out there who do a fantastic job.

    The arguments for different time zones, cultural differnences etc. are moot in my opinion - those are all known facts which can be easily dealt with. In my experience, problems with outsourced projects tend to be caused largely by the buyer - wanting to save money, and not taking the time to research and communicate with their freelancers properly.

    I've outsourced a number of projects over the past year and been very happy with most of the results. When there has been a problem I'm realised that it was mainly a breakdown of communication, and largely my fault, and I've learned from it.

    Ranting and complaining about outsourcing, as so many people seem to at the moment, won't help - it's here to stay! So all parties should endevour to learn, improve and turn outsourcing into the valid and respected business it should be.
  • Quality is a result of engineering processes.

    I think this is unequivocally false. It might hold true for making physical widgets, but in my experience software quality (and productivity) is a direct consequence of the talent and knowledge level of the programmer.

    The most serious problem I have found in working with an outsourced programming team is that the contracting firm has little visibility into the makeup and selection of the team. Usually, if you contract a ten person team from the average Mumbai outsourcing shop, their team lead will be a pretty decent programmer and there will be two or three guys who are satisfactory, but the rest will be a net drag on your productivity.

    A bad programmer produces less work, and that work is inferior: more bugs, poor structure, slow algorithms... Code review (which is absolutely essential when working with outsourced teams) takes a lot longer, and you need more rounds of it. Past a certain point the drag on the technical leadership will become prohibitive.

    If your process discipline is not 100% (and for most small software companies, it isn't), those guys on the left-hand side of the bell curve are going to slip some grotesque, monstrous logic errors into your programs.

    I think there's definitely a market in Canada and in the U.S. for "creme de la creme" outsourcing teams: people two to three sigma right of centre on the talent curve, highly productive programmers with MSc.-level computer science backgrounds, who are at least somewhat familiar with Unix (I've found that most Indian programmers aren't).

    The traditional draw of outsourcing to India has been that you can get a programmer for 30%-50% of what you'd have to pay one here. If we had it to do again, I think we'd gladly pay double or triple that salary to get a smaller team of really exceptional people.
  • Greg,

    Without attempting to characterize your experiences (and I am certain yours is a very valid experience as are likely to be many other different ones), one of the issues I have indeed pointed out is a reduction in average skill levels and the economic drivers which are leading to that.

    I think a customer who is not satisfied with the service, should change providers. But to imagine that you cannot find people two to three sigma right of the centre on talent curve in India is unlikely to be accurate. You'll certainly find them if you look hard enough (I would like to believe I have worked with scores of such people myself both in US and in India).

    With regards to engineering processes, there are firms which will have rigorous training and mentoring capabilities to ramp up the skill levels, and there are many who dont. You will find all kinds of firms in all corners of the world. Caveat Emptor would be my operating advice.

    Dhananjay
  • I will correct myself slightly here. In my limited and empirical experience, a large number of the highly talented programmers in India have since moved to United States, and a large number of those who didn't have moved into Management roles (both transitions I guess are highly driven by economic considerations). So it is a relatively harder to find right of 2/3 sigma programmers who are also highly experienced, in India. YMMV
  • In case to avoid the problems of outsourcing, the vetting process must be really thorough. Visibility is sure a problem, hence constant status checks are necessary IMHO. This would help in case of exiting a bad provider as early as possible. Still, productivity is lost if all we do is test providers. We should try the best in the vetting process to eliminate the bad apples.

    From my experience, there are sure good people in the programming team, but most of them are scattered throughout different providers and different teams. Most of the setup is just as what Greg mention, a capable team lead, followed by few other capable team members and the rest are just net drag. I am not saying that every team is like this, but even with big providers, they tend not to put all their eggs in one basket, and they will handle the risk by distributing their top talents rather than keeping them as one team.

    And to find top talents are sure is a problem in the market. If all you depends are top talents, then its going to be very hard to bill the client and meet your sales target. This is what I believe IMHO to be the reason for such exercise (of distributing talents and just keep adding people in the team even if it can be a drag).

    I would just say, that the system work for the providers that way. Anybody considering outsourcing, just need to shop a bit harder I suppose.
  • An interesting and detailed article. I particularly like your points about short term economic advantage, at least from Wall Streets point of view, and something being better than nothing. Both of these are very strong forces that can't be ignored, even though most people wish they could be!
  • Thats a lot of information and analysis. But I always thought the quality of software was bad because somehow the client was never focussed on it. If I were a client paying for some software, then it better met my standards. If we think it is crappy, but the client is happy : is the software really crappy? Maybe not. It is perhaps just what is enough. That situation needn't change at all, right?

Add New Comment

Returning? Login