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.
And yes, if a company decides to outsource with low price being the overshadowing priority, they are likely to end up with the amazingly low price and amazingly low quality vendors.
But you sure can't count on this happening, and, by the very nature of this effect, it doesn't scale, and it isn't repeatable.
I need to figure out how to get in on that action, as recipient of the outsourcing work.
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.
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.
Unfortunately, that's been going on for a while now with the big consulting agencies.
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.
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.
It's hard for a lot of people on here to imagine dealing with 100k+ other coworkers but at a point you oftentimes have to abstract away what makes people human to work in most large corporations. I'm not advocating that this is correct, but much like slavery and flat world theory, I hope this becomes outdated and struck out as both completely ineffective from a business standpoint as well as unconscionable.
Really? Seems like most people describe it these days as a craft.
> Assembly lines reproduce a product model in volume.
Right, and software development is the process of building the assembly line.
> People forget that developing the model takes loads of time from designers and engineers.
But they know design an assembly line for a new task takes loads of time from designers and engineers...
> Software developers are the designer, engineer, and assembler all at once.
You can break of that work if you are working on a project of sufficient scale.
It's more like the process for developing the prototype.
Working myself for a company of 150K+ employees, I can confirm this is totally true.
I hate a lot of high-level business speak like "resources", but what I've come to realize is that one cannot think of 150K people as individuals. It's too much for the human mind. If you see this as an indictment of large corporations, I wouldn't blame you. Just realize it's a reality of operating inside them.
A resource isn't intrinsically a fungible commodity (when they are, we call them "commodities" ;-); often they are unique. The common trait of resources from a businesses perspective is that they are valuable to the business. Sure, I'd like to think I have more significance to this world as a person, but the day my employer doesn't see me as valuable is the day I start sending my resume around...
The other way to look at it is that while employees are individuals, they all take a paycheck. So, on the cost side, employees are all just different sized paychecks. When you are looking to assign employees to a task, you absolutely think about which individuals could/should be dong what, but before that, there is a decision about how much in the way of paychecks, if any, you ought to burning on that work. That first decision has little to do with the individuals involved.
A person is not a resource outside of contexts in which chattel slavery exists. Labor is a resource, of which persons -- laborers (whether independent contractors or employees) -- are contracted suppliers, not units.
This dehumanizing confusion of supplier with the resource they supply seems to only happen with labor.
Your reference to chattel inspired me. Consider the cow. Cows are resources. There are a ton of rules about what one can and cannot do with cows, but businesses still think of the "cow" as their resource, and "beef" and "milk" as some of the value they get from the resource.
Now, to your point on slavery, the rules for what you can and cannot do to people are very different from cattle. Of course, slavery is pretty irrelevant to whether someone is considered fungible (owning people is horrible, but it doesn't change whether they are interchangeable or not).
In practice resources are often suppliers and often the value the business extracts from them are provided under contract or at least a generalized regulatory framework. You are again confusing properties of certain kinds of resources with properties of resources in general.
Labour is very much how you marshall your "people" resources. It's a far more impersonal window through which to view people's relationships with businesses.
> Labor is a resource, of which persons -- laborers (whether independent contractors or employees) -- are contracted suppliers, not units.
Check out the definition of a "resource". It's the asset you draw upon to accomplish something.
Strictly speaking, the real "resource" is the employment or contract with the person, not the labour. However, thinking in those terms is terribly impersonal and not terribly useful for reasoning about a business (outside of legal disputes); in reality the person(s) under a contract correlate with suitability, outcomes, etc. a heck of a lot more than the contracts themselves. So what you really think in terms of are the people, not the contracts.
I have a hard time fathoming how it is dehumanizing to suggest that labour from one person is not the same as labour from another.
I don't get where this idea that developers can be easily replaced come from. No other profession is, and really, not even machines work this way.
Someone needs to explain to me why would this be a bad thing?
They bleed lots of money and that allows the Darwinistic decimation process to kick in and ultimately wipe them out.
A fool and his money are easily parted, and that is how it should be.
You see, someone who is not capable of programming, should not be allowed to manage programmers, because that simply amounts to an insult. He cannot do what you can do. Therefore, he is an idiot. Nobody wants to take orders from an idiot. Every single business on the planet is now, one way or another, turning into a technology platform. This means that in the end, it is programmers who will own and control everything, and not that bunch of idiots.
Humans are social animals. The power to cause (or prevent) change in organizations is political in nature. The power to affect operations through technology is at best instrumental to the power to decide what effect is to be implemented. By ignoring these facts, programmers forego the opportunity to be seen as valuable allies and turn themselves into exploitable resources. No amount of progress, or "platformization" is going to change that.
Sure, getting high paying jobs with little accountability can be kind of cool, in the short term. But you need to think what happens next. If social Darwinism is true, idiot managers will die out and be replaced with more competent managers. It will take years, but at the end of day, they will wise up. And if so many of them see programmers as a threat they will cut our jobs.
To a degree, this is what we are seeing now. The older generation of managers learned that programmers are unreliable, so they outsource not to save money, but to mitigate the risk of having to deal with programmers directly. The next generation is learning that the 3rd parties that isolate them from programmers are unreliable too. I expect the next generation will be very reluctanct to have in house development at all, and that they will limit themselves to existing products from reputable companies, if at all.
Hard to tell what happens when that option is also shown to be not reliable.
I hate this trope. There are thousands of professions out there, and most of them involve some kind of specialized knowledge/ability/skill. Do you really expect the head of your organization, the person least likely to have time to do independent work, to be the one with mastery of all the activities in the organization?
> He cannot do what you can do. Therefore, he is an idiot.
This one is even worse. It's not like programmers know how to do everyone else's jobs, and they aren't idiots.
> Nobody wants to take orders from an idiot.
Some cynical folks have argued that the advantage is that idiots are easily manipulated...
> Every single business on the planet is now, one way or another, turning into a technology platform.
Technology != software, and even if it did, very few businesses are viable as a software platform. Software is becoming an increasingly intrinsic part of most businesses, but so is accounting, legal, hr, management...
> This means that in the end, it is programmers who will own and control everything, and not that bunch of idiots.
I can imagine an accountant thinking much the same thing a century ago...
It's considered unethical for doctors or lawyers to have their work supervised by anyone who isn't a doctor or lawyer. They enforce the rule through professional conduct rules and boards. the result is very high prestige, pay, and working conditions for people with similar skills and education to programmers.
But the atomistic libertarianism and lack of solidarity among programmers makes us targets of mass low wage immigration, outsourcing, and every kind of unpleasant work situation.
With lawyers (more familiar there than with doctors) I don't think that's usually the case; the ABA model rules don't prohibit lawyers from being supervised by non-lawyers (though they do prohibit lawyers from co-owning law firms with non-lawyers, or sharing legal fees with non-lawyers, and they do prohibit lawyers from allowing their employer to "to direct or regulate the lawyer's professional judgment" in providing legal services -- whether or not the employer is a lawyer; this doesn't prevent supervision of the lawyer as an employee, it just essentially means that the lawyer doesn't have a Nuremberg defense of "just following orders" for professional nonfeasance or misconduct.)
http://www.americanbar.org/groups/professional_responsibilit...
I've supervised lawyers, though I'm not a lawyer. I know the same applies to other people with regards to doctors. The trade establishes rules they can't violate, but there are a ton of caveats on that. Regardless, those restrictions are actually needed by the organizations for specific roles. If a programmer was needed in a similar way for a specific role, it'd largely work out the same way. The main difference is there'd be no independent review board that has no idea what is going on in the day-to-day unless otherwise alerted.
The prestige/pay/working conditions thing is more a result of a trade group, and the consequent standards for people even being part of the trade, than due to supervision by those who lack skill expertise.
If you restrict yourself to the subset of programmers who have similar education, training, and professional validation processes as doctors & lawyers, I think you'll find a lot of prestige, pay, and quality work conditions (lawyers and doctors will tell you that it isn't quite as good as you imagine anyway).
Agreed. How would you even run a small town according to this "logic"? You would need to be a professional in many different fields. That's why you have advisers for, and that's why a good manager will listen to the people he is managing.
Better yet -- they bleed lots of money but don't die out, due to being hugely profitable, so they continue bleeding lots of money and we finally get the trickle-down economy Reagan promised us.
> inept endive
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.
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.
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.
Right now he'll be hoping to profit by bringing things back in-house so they can be outsourced again later.
It is entirely possible to pay less for the same talent. My thinking is that he got lucky though.
If you start out underpaying, you can still overpay thereafter. Here is a quick top-of-my-head list of major software costs that can come up (not too far) down the line, after paying initial development wages:
- Documentation turns out to be nonexistent or written in a way that is hard to decipher, or wrong. (This seems more likely with outsourcing because heck, you didn't specify that you wanted the code documented, and it'll take hours to add all that, plus you might pay more later if it's not there...)
- Serious bugs are lurking that require a little time to discover.
- Although the system demo'd well with initial tests, it collapsed when asked to scale slightly; e.g. it exposed a bad choice of algorithm that blew up with large N. Sometimes bad algorithms from inexperienced developers can create a catastrophically large amount of refactoring work.
- The developers took short-cuts and exposed the company to a legal minefield (e.g. copying something or injecting patented or GPL'd code without asking), rendering their working and brilliantly-implemented solution unusable. Now what...even if you can argue that it's their fault, you're probably going to be paying lawyers for something (defense or lawsuits).
- The system does seem to do what it's supposed to do but it turns out you didn't specify it quite right and it integrates poorly into your environment in some way. So, great: it's done, it's here, it runs but you still aren't getting anything out of it because you have to spend more time and money to bring it to a usable state internally. Typically this doesn't happen with internally-developed systems because the people are familiar all along with the idiosyncrasies of the environment.
Even at a cheaper hourly rate, how many more times are you going to go back to the provider (just a few more hours at a cheap rate to fix the next problem...) before you've gained nothing? Much less the fact that you have zero actual employees who understand what you bought so if the provider ever goes out of business or triples its prices, you incur another "new" cost: hiring or redirecting your own people to figure out this thing that you bought and now have to maintain yourself.
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.
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."
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.