9 ms·

I would say it never really has worked; there is no "anymore". One problem in outsourcing is the thinking that programmers are somehow easily replaced; the "ju

I would say it never really has worked; there is no "anymore". One problem in outsourcing is the thinking that programmers are somehow easily replaced; the "just find 'a' developer" idea, with little to no thought put into whether it may matter if the chosen team has any idea what they're doing. Two anecdotes. Years ago I was given such a team, to maintain a system primarily written in two different languages; the manager in charge gave me two guys from the other side of the world who were to be "taking over" the project despite not knowing how to program in either language, and there was no arguing this point. On another project, a resource from far away was graciously donated to me to help with a C++ project; I later realized he had chosen to recreate several container classes in C++ as if he'd never heard of the STL. Another problem is the fundamental misunderstanding of culture. Managers in the U.S. seem surprised when they encounter wildly different behaviors overseas (gee, it's almost as if they had hired someone from a completely different part of the world!). For instance, I have encountered remote groups that are astoundingly good at self-preservation, who will basically change their minds and do whatever they want at the last minute to prop up their team at the expense of your project. Individuals, too, may have side projects that they care about much more than anything you have asked them to do.

JoeAltmaier 11y ago
Agreed. 20 years, and I've never seen a return on an outsourced project. The overseas company whittles the specs down so far, your own guys could do it in a weekend. The cost of managing is larger than the value received: barriers include language, timezone, network access, culture, currency, import/export rules. The culture one is huge. Many cultures, a worker won't contradict a boss for any reason. So you're trying to get an expert opinion out of them about how to proceed, they're just saying "Uh huh, yes boss".
- cubancigar11 11y ago
  Funny. In my experience telling something as it is is a very easy way to piss of the client, who in general have huge ego that they are from a superior culture.
  - cookiecaper 11y ago
    One of the primary benefits of an external contractor is that they are mostly unaffected by whatever politics are occurring within the company. This means that they're more likely to give direct, honest feedback, and they won't worry very much about whose feelings it hurts. This is supremely valuable in most organizations, and impossible for most employees to provide if they want to stick around for more than a few months. There are unreasonable people everywhere, of course, so it's not that weird to find a client who doesn't understand the value of this service.
  - thothamon 11y ago
    Even if that is true (which it may well be), it's yet another landmine for companies who seek solutions via outsourcing. I'd agree with OP on this. I've never seen a distributed, outsourced approach work. The product has always been poor or even worthless. Having said that, I have seen distributed, in-house projects work, sometimes very well, even when the teams were internationally distributed, and even with moderate language barriers.
- MortenK 11y ago
  You should try other outsourcing destinations. Large timezone differences are indeed a hurdle, and culture differences is always underestimated. Add to that the general ineptitude of managing projects in large companies, and you have a recipe for disaster. In Western Europe, the most compatible culture and therefore easiest place to start, is Eastern Europe and Russia. If you are in the US, I'd personally just outsource to US companies in the midwest. Some of my western European clients are actually doing this now, as for example NC hourly rates are lower than Moscow rates. Managing projects where you have big cultural differences require many years of experience in that particular area. Even then, it requires a much higher project management effort. If management of a project with a local team take on average 10% of total project time, a project with developers in a markedly different work culture will easily take 20-30% of time spend.
  - IndianAstronaut 11y ago
    The cost of living in most Indian cities is higher than the midwest. Good devs there will cost quite a bit.
    - josephjrobison 11y ago
      Never heard of that before - what's some good data to read more about that?
      - Scuds 11y ago
        https://www.expatistan.com/cost-of-living/comparison/st-louis/mumbai https://www.expatistan.com/cost-of-living/comparison/st-loui... Eh... I dunno how accurate this is.
      - IndianAstronaut 11y ago
        You can look up prices on some Indian real estate sites such as olx.in. Try and focus on tech areas, not some random parts of cities.
  - JoeAltmaier 11y ago
- VOYD 11y ago
  And now the bigger software companies are opening "research centers" in the offshore countries and just plain moving the jobs there. Specifically China, which was the big deal when the president of China recently met with Facebook, Twitter, Google, and Apple at Microsoft's main campus.
  - mtberatwork 11y ago
    > And now the bigger software companies are opening "research centers" in the offshore countries and just plain moving the jobs there. Unfortunately, that's been going on for a while now with the big consulting agencies.
  - artpar 11y ago
    I guess that was the Indian Prime Minister. It could be both though.
- HillRat 11y ago
  Or they will require such detailed functional specs that by the end you're almost literally just paying for ten fingers to do the typing. An example that I wish weren't true: one specification had detail to the level of specifying that a particular form required a button to submit the form. The returned product had a button titled "Submit the Form." It did nothing, because the specification did not explicitly say to submit the form when the button was clicked.
  - dmux 11y ago
    This is gold.
  - sopooneo 11y ago
    A web app I inherited, for which I do not have the original spec, and initially developed by an outsourced offshore team, had one route that was literally "/obscure/reset_password?user_id=x". A light dawned when I realized they must have been asked to provide an unguessable or "obscure" endpoint for account actions.
huherto 11y ago
I have seen the same problems on in-sourced projects. You still need capable engineers. May be managers who outsource their projects tend to be more clueless. I give you that.
- thothamon 11y ago
  Software is very hard to do well, and you're right that many in-sourced projects fail or suffer extensive problems. But when you outsource, you keep all the normal, natural problems of software development and add many more enormous burdens and difficulties on top of that. In my experience, the failure rate of outsourced projects is much higher than that of in-sourced projects. We can't gloss over the differences by just saying that they both experience failures. I agree that capable engineers are very important, but I have seen more than one project with high-quality engineers fail. Of course, you very rarely get high-quality engineers with outsourcing.
  - huherto 11y ago
    I completely agree with you. I was just trying to stress the importance of having capable engineers. It seems that people forget about it when they outsource. Furthermore, you actually need better engineers if you outsource.
chris_wot 11y ago
Oh boy... That leads on to another thing that most non-technical (and even some technical!) managers don't understand: IT people are not drop-in modular components that will instantly work! Here's an example: I did some BI work in Qlikview. The existing reports for a particular division were badly written, and were each loaded manually for each client. Due to a number of reasons, we weren't able to change this situation immediately, but we kept what we had running even though it was incredibly inefficient. Eventually it got to the stage where we needed to get the reports working in an automated fashion. I had a solution I was willing to work on, but was unable to find the time to do it as my primary responsibility was to another BI project. The manager kept putting off getting new resources, and tried to "fix" the reports himself, only ending up breaking them completely. The solution that management came up with was to employ a new resource. However, by the time they employed the new person they had 3 days to get the reports working. The problem was that even though the new person understood Qlikview exceptionally well, he didn't understand (and had no way of knowing immediately!): 1. What the dashboards needed to show (not documented) 2. The data sources used in the Qlikview dashboard 3. The way the Qlikview load script had been coded As the guy was really, really good it ended up taking just under two weeks to get to grips with the underlying data structures and business requirements. The implementation to fix the numerous dashboards took another week. Then fixing any issues took another week and a half. So that was about a month and a half of work to get the guy up to speed, then implement a solution. Management expects someone to be like a field replicable unit, that you can drop-in and replace on a project. But that is not the way these things work - the nature of people and projects (which are each different) is that there is ALWAYS a lead time - sometimes up to months depending in the complexity of the project - where the new person you employ (no matter how good they are) needs to familiarise and understand the systems and requirements of the business before they can actually do productive work.
- pnathan 11y ago
  Orthogonal nit, you tripped over one of my soapboxes: "employ a new resource". People are not resources, like a vein of coal. They are individual. Which was your point. But using the word "resource" instead of "person" perpetuates bad ideas.
betandr 11y ago
It is an inherent issue with the industry, demonstrated by the strategy of adding more people to a project and expecting productivity to increase on a linear scale. Although, intuitively, people surely understand that writing software is a complex task it's surprising how many people seem to just assume it's just banging away at keys on a keyboard.
blakecallens 11y ago
The simple truth is that people who outsource development to firms in developing nations are trying to get more than they're willing to pay for, which has never worked - ever.
matwood 11y ago
> I would say it never really has worked; there is no "anymore". Completely agree. I saw this trend when I managed pieces of my team in the Philippines. Nothing wrong with the people there, but you still get what you pay for. When outsourcing is supposed to be 'cheap' people who were any good would be gone in a month or less because I wasn't allowed to pay them more. The second part is that very little software is 'here is a complete spec, now type in the code'. It is usually I have an idea and maybe a rough spec and I need a MVP written to start exploring. During this exploration having my software people learn and explore with me is critical. Add in the timezone costs, communication costs, costs of actual good people, turnover, and pretty soon the costs are what it would take to have someone local.
vram22 11y ago
>"a resource"
dragonwriter 11y ago
> I would say it never really has worked; there is no "anymore". That's the point of the article. To quote the final sentence: The point of all this is that outsourcing simply can't work, because your business interests can't be aligned with the interests of your outsourcing "partner."
nathanb 11y ago
This is interesting, because you're ignoring the fact that the author worked in this exact business for some time and claims that it did once work and doesn't anymore. Either he was deluded at the time and overcame his delusion without ever realizing he was deluded (which is possible) or there's more to it than you make it seem. Because I think someone who says "this used to work and now it doesn't" may have something profound to say that the person saying "this has never worked" needs to hear. Perhaps you're right and software outsourcing has never worked, in the sense that from a total cost standpoint it has never been better to contract development of a software project to a third party than to create it in house. I don't agree with this, but we'll accept it for the point of argument. You're still ignoring his point that the change in economics has caused a cultural change in the attitudes of those who lead outsourcing entities. The article claims that previously, the economics allowed them the luxury of trying to deliver a result to their customers. Now, they are not able to do so because the economics require them to milk their customers for every cent in order to break even. This may not directly affect you if you have always believed that outsourcing doesn't work and you disagree with his opening statements attempting to rebut that mindset. But it's still an interesting view from the inside.
- gaius 11y ago
  The sort of person who outsources will say whatever is most profitable for them at any moment in time. Right now he'll be hoping to profit by bringing things back in-house so they can be outsourced again later.
- sheepmullet 11y ago
  > This is interesting, because you're ignoring the fact that the author worked in this exact business for some time and claims that it did once work and doesn't anymore. Reading between the lines, it "worked" because it was an incredibly high margin business and so when a project wasn't on track they could simply throw many more developers into the mix to get it over the line. > Either he was deluded at the time and overcame his delusion without ever realizing he was deluded Or I suspect they simply have a different idea of "worked". I suspect the OP means was better (I.e. Cheaper, quicker, or of a higher quality) than an internal team could do. Whereas I suspect the writer meant he could keep clients reasonably happy and deliver ok software.

JoeAltmaier 11y ago

Agreed. 20 years, and I've never seen a return on an outsourced project. The overseas company whittles the specs down so far, your own guys could do it in a weekend. The cost of managing is larger than the value received: barriers include language, timezone, network access, culture, currency, import/export rules. The culture one is huge. Many cultures, a worker won't contradict a boss for any reason. So you're trying to get an expert opinion out of them about how to proceed, they're just saying "Uh huh, yes boss".

cubancigar11 11y ago
Funny. In my experience telling something as it is is a very easy way to piss of the client, who in general have huge ego that they are from a superior culture.
- cookiecaper 11y ago
  One of the primary benefits of an external contractor is that they are mostly unaffected by whatever politics are occurring within the company. This means that they're more likely to give direct, honest feedback, and they won't worry very much about whose feelings it hurts. This is supremely valuable in most organizations, and impossible for most employees to provide if they want to stick around for more than a few months. There are unreasonable people everywhere, of course, so it's not that weird to find a client who doesn't understand the value of this service.
- thothamon 11y ago
  Even if that is true (which it may well be), it's yet another landmine for companies who seek solutions via outsourcing. I'd agree with OP on this. I've never seen a distributed, outsourced approach work. The product has always been poor or even worthless. Having said that, I have seen distributed, in-house projects work, sometimes very well, even when the teams were internationally distributed, and even with moderate language barriers.
MortenK 11y ago
You should try other outsourcing destinations. Large timezone differences are indeed a hurdle, and culture differences is always underestimated. Add to that the general ineptitude of managing projects in large companies, and you have a recipe for disaster. In Western Europe, the most compatible culture and therefore easiest place to start, is Eastern Europe and Russia. If you are in the US, I'd personally just outsource to US companies in the midwest. Some of my western European clients are actually doing this now, as for example NC hourly rates are lower than Moscow rates. Managing projects where you have big cultural differences require many years of experience in that particular area. Even then, it requires a much higher project management effort. If management of a project with a local team take on average 10% of total project time, a project with developers in a markedly different work culture will easily take 20-30% of time spend.
- IndianAstronaut 11y ago
  The cost of living in most Indian cities is higher than the midwest. Good devs there will cost quite a bit.
  - josephjrobison 11y ago
    Never heard of that before - what's some good data to read more about that?
    - Scuds 11y ago
      https://www.expatistan.com/cost-of-living/comparison/st-louis/mumbai https://www.expatistan.com/cost-of-living/comparison/st-loui... Eh... I dunno how accurate this is.
    - IndianAstronaut 11y ago
      You can look up prices on some Indian real estate sites such as olx.in. Try and focus on tech areas, not some random parts of cities.
- JoeAltmaier 11y ago
VOYD 11y ago
And now the bigger software companies are opening "research centers" in the offshore countries and just plain moving the jobs there. Specifically China, which was the big deal when the president of China recently met with Facebook, Twitter, Google, and Apple at Microsoft's main campus.
- mtberatwork 11y ago
  > And now the bigger software companies are opening "research centers" in the offshore countries and just plain moving the jobs there. Unfortunately, that's been going on for a while now with the big consulting agencies.
- artpar 11y ago
  I guess that was the Indian Prime Minister. It could be both though.
HillRat 11y ago
Or they will require such detailed functional specs that by the end you're almost literally just paying for ten fingers to do the typing. An example that I wish weren't true: one specification had detail to the level of specifying that a particular form required a button to submit the form. The returned product had a button titled "Submit the Form." It did nothing, because the specification did not explicitly say to submit the form when the button was clicked.
- dmux 11y ago
  This is gold.
- sopooneo 11y ago
  A web app I inherited, for which I do not have the original spec, and initially developed by an outsourced offshore team, had one route that was literally "/obscure/reset_password?user_id=x". A light dawned when I realized they must have been asked to provide an unguessable or "obscure" endpoint for account actions.

huherto 11y ago

I have seen the same problems on in-sourced projects. You still need capable engineers. May be managers who outsource their projects tend to be more clueless. I give you that.

thothamon 11y ago
Software is very hard to do well, and you're right that many in-sourced projects fail or suffer extensive problems. But when you outsource, you keep all the normal, natural problems of software development and add many more enormous burdens and difficulties on top of that. In my experience, the failure rate of outsourced projects is much higher than that of in-sourced projects. We can't gloss over the differences by just saying that they both experience failures. I agree that capable engineers are very important, but I have seen more than one project with high-quality engineers fail. Of course, you very rarely get high-quality engineers with outsourcing.
- huherto 11y ago
  I completely agree with you. I was just trying to stress the importance of having capable engineers. It seems that people forget about it when they outsource. Furthermore, you actually need better engineers if you outsource.

chris_wot 11y ago

Oh boy... That leads on to another thing that most non-technical (and even some technical!) managers don't understand: IT people are not drop-in modular components that will instantly work! Here's an example: I did some BI work in Qlikview. The existing reports for a particular division were badly written, and were each loaded manually for each client. Due to a number of reasons, we weren't able to change this situation immediately, but we kept what we had running even though it was incredibly inefficient. Eventually it got to the stage where we needed to get the reports working in an automated fashion. I had a solution I was willing to work on, but was unable to find the time to do it as my primary responsibility was to another BI project. The manager kept putting off getting new resources, and tried to "fix" the reports himself, only ending up breaking them completely. The solution that management came up with was to employ a new resource. However, by the time they employed the new person they had 3 days to get the reports working. The problem was that even though the new person understood Qlikview exceptionally well, he didn't understand (and had no way of knowing immediately!): 1. What the dashboards needed to show (not documented) 2. The data sources used in the Qlikview dashboard 3. The way the Qlikview load script had been coded As the guy was really, really good it ended up taking just under two weeks to get to grips with the underlying data structures and business requirements. The implementation to fix the numerous dashboards took another week. Then fixing any issues took another week and a half. So that was about a month and a half of work to get the guy up to speed, then implement a solution. Management expects someone to be like a field replicable unit, that you can drop-in and replace on a project. But that is not the way these things work - the nature of people and projects (which are each different) is that there is ALWAYS a lead time - sometimes up to months depending in the complexity of the project - where the new person you employ (no matter how good they are) needs to familiarise and understand the systems and requirements of the business before they can actually do productive work.

pnathan 11y ago
Orthogonal nit, you tripped over one of my soapboxes: "employ a new resource". People are not resources, like a vein of coal. They are individual. Which was your point. But using the word "resource" instead of "person" perpetuates bad ideas.

betandr 11y ago

It is an inherent issue with the industry, demonstrated by the strategy of adding more people to a project and expecting productivity to increase on a linear scale. Although, intuitively, people surely understand that writing software is a complex task it's surprising how many people seem to just assume it's just banging away at keys on a keyboard.

blakecallens 11y ago

The simple truth is that people who outsource development to firms in developing nations are trying to get more than they're willing to pay for, which has never worked - ever.

matwood 11y ago

> I would say it never really has worked; there is no "anymore". Completely agree. I saw this trend when I managed pieces of my team in the Philippines. Nothing wrong with the people there, but you still get what you pay for. When outsourcing is supposed to be 'cheap' people who were any good would be gone in a month or less because I wasn't allowed to pay them more. The second part is that very little software is 'here is a complete spec, now type in the code'. It is usually I have an idea and maybe a rough spec and I need a MVP written to start exploring. During this exploration having my software people learn and explore with me is critical. Add in the timezone costs, communication costs, costs of actual good people, turnover, and pretty soon the costs are what it would take to have someone local.

vram22 11y ago

>"a resource"

dragonwriter 11y ago

> I would say it never really has worked; there is no "anymore". That's the point of the article. To quote the final sentence: The point of all this is that outsourcing simply can't work, because your business interests can't be aligned with the interests of your outsourcing "partner."

nathanb 11y ago

This is interesting, because you're ignoring the fact that the author worked in this exact business for some time and claims that it did once work and doesn't anymore. Either he was deluded at the time and overcame his delusion without ever realizing he was deluded (which is possible) or there's more to it than you make it seem. Because I think someone who says "this used to work and now it doesn't" may have something profound to say that the person saying "this has never worked" needs to hear. Perhaps you're right and software outsourcing has never worked, in the sense that from a total cost standpoint it has never been better to contract development of a software project to a third party than to create it in house. I don't agree with this, but we'll accept it for the point of argument. You're still ignoring his point that the change in economics has caused a cultural change in the attitudes of those who lead outsourcing entities. The article claims that previously, the economics allowed them the luxury of trying to deliver a result to their customers. Now, they are not able to do so because the economics require them to milk their customers for every cent in order to break even. This may not directly affect you if you have always believed that outsourcing doesn't work and you disagree with his opening statements attempting to rebut that mindset. But it's still an interesting view from the inside.

gaius 11y ago
The sort of person who outsources will say whatever is most profitable for them at any moment in time. Right now he'll be hoping to profit by bringing things back in-house so they can be outsourced again later.
sheepmullet 11y ago
> This is interesting, because you're ignoring the fact that the author worked in this exact business for some time and claims that it did once work and doesn't anymore. Reading between the lines, it "worked" because it was an incredibly high margin business and so when a project wasn't on track they could simply throw many more developers into the mix to get it over the line. > Either he was deluded at the time and overcame his delusion without ever realizing he was deluded Or I suspect they simply have a different idea of "worked". I suspect the OP means was better (I.e. Cheaper, quicker, or of a higher quality) than an internal team could do. Whereas I suspect the writer meant he could keep clients reasonably happy and deliver ok software.