Outsourcing Killed By Django And Ruby On Rails(blog.awarelabs.com)
blog.awarelabs.com
Outsourcing Killed By Django And Ruby On Rails
http://blog.awarelabs.com/?p=80
14 comments
What is there for C++ besides CppCMS?
http://art-blog.no-ip.info/cppcms/blog
http://art-blog.no-ip.info/cppcms/blog
Also not all apps are database backed web apps.
Code has become a commodity. All you have to do is write the documentation very specifically, and some guy in India with a lower standard of living and lower wage will do it for you. No, the code might not be optimized or highly readable (unless you specifically pay him and instruct him to build it in such a way), but the fact is that programming has become easier to do. Yes, iPhone app development is really expensive right now because it's difficult. Objective C is not a difficult language, but the process of building those applications forces you to think them through. You basically have to know everything well in advance of starting a project. It's not really what I would call a "rapid prototyping-friendly approach." So in some regards, iPhone development and Flex development (or any RIA development for that matter) is now expensive. But it won't always be. It will continue to become easier.
You don't think that other countries won't adopt newer languages and continue to perform them cheaply? If it takes 100 hours in PHP, then people will start asking for 20 hours in RoR. And maybe now not everyone knows RoR, but those outsourced developers will pick it up if they have to. They will pass the cost savings on as well. And yet again, we're back into this cycle of code and applications as a commodity.
The only way to beat outsourcing is to be creative. The one thing you have against anyone else who wants to do outsourcing is to take zero shortcuts. The outsourced projects will for the most part fail, although they'll still happen. You'll see guys from Goldman Sachs dumping some money into these lame projects that will never surface because some YC startup was willing to put in the wrench time to build a more holistic approach: not just code, but design, and usability, and culture. That is sustainable. An outsourced project is not (unless your Kevin Rose and promote your idea on TechTV). By the way, I got to meet Byrne, and he's tremendous. I would argue he's one exception to the rule that outsourced programmers are not creative.
The reason our engineers drop out is because they don't see how the material they're being taught is relevant or at all interesting. There's too much science, math, and analysis when there should be more of a balance of practice, drawing, design, ethics, and art. It sounds really Utopian, I know, but you have to ask (1) why are drop out rates for engineers >50% in the country, but <2% at schools that emphasize drawing, creativity and practice along with the engineering courses, (2) do these outsourced projects really deserve all of the hype they receive? I would say they don't, and there's no language that will "kill outsourcing." There never will be.
You can save money on projects, and lure the project managers to hire you instead of someone in India, sure. But do you really want to work with those people who are just out to find a quick dollar? And like I said, you don't think someone in India will embrace faster/cheaper languages if the market starts demanding them?
I hope I didn't completely miss the point on this. Perhaps I did, but I at least thought it was worth discussing outsourcing and creativity in engineers.
You don't think that other countries won't adopt newer languages and continue to perform them cheaply? If it takes 100 hours in PHP, then people will start asking for 20 hours in RoR. And maybe now not everyone knows RoR, but those outsourced developers will pick it up if they have to. They will pass the cost savings on as well. And yet again, we're back into this cycle of code and applications as a commodity.
The only way to beat outsourcing is to be creative. The one thing you have against anyone else who wants to do outsourcing is to take zero shortcuts. The outsourced projects will for the most part fail, although they'll still happen. You'll see guys from Goldman Sachs dumping some money into these lame projects that will never surface because some YC startup was willing to put in the wrench time to build a more holistic approach: not just code, but design, and usability, and culture. That is sustainable. An outsourced project is not (unless your Kevin Rose and promote your idea on TechTV). By the way, I got to meet Byrne, and he's tremendous. I would argue he's one exception to the rule that outsourced programmers are not creative.
The reason our engineers drop out is because they don't see how the material they're being taught is relevant or at all interesting. There's too much science, math, and analysis when there should be more of a balance of practice, drawing, design, ethics, and art. It sounds really Utopian, I know, but you have to ask (1) why are drop out rates for engineers >50% in the country, but <2% at schools that emphasize drawing, creativity and practice along with the engineering courses, (2) do these outsourced projects really deserve all of the hype they receive? I would say they don't, and there's no language that will "kill outsourcing." There never will be.
You can save money on projects, and lure the project managers to hire you instead of someone in India, sure. But do you really want to work with those people who are just out to find a quick dollar? And like I said, you don't think someone in India will embrace faster/cheaper languages if the market starts demanding them?
I hope I didn't completely miss the point on this. Perhaps I did, but I at least thought it was worth discussing outsourcing and creativity in engineers.
> All you have to do is write the documentation very specifically
And that's where most software projects fail. If there's one great thing about the agile development movement it's the involvement of customers in the process so that they get the software they actually want, not what they thought they wanted at the beginning.
How much does fully specifying a piece of software cost? Now compare that with a loose specification and an engineer who's in contact with the customer and refining the application as requirements are discovered.
And that's where most software projects fail. If there's one great thing about the agile development movement it's the involvement of customers in the process so that they get the software they actually want, not what they thought they wanted at the beginning.
How much does fully specifying a piece of software cost? Now compare that with a loose specification and an engineer who's in contact with the customer and refining the application as requirements are discovered.
> All you have to do is write the documentation very specifically...
And then compile it. That is to say, if you've written your spec sufficiently precisely, then it _is_ code, and will compile, thereby sparing the need to hire programmers. The reason that you need programmers is that you haven't written the specs specifically enough, usually because it's essentially impossible to specify (many kinds of) software that accurately a priori.
Furthermore, and on this point I think we agree, there needs to be a fairly wide channel of communication between the engineer and the product manager exactly so that ambiguities in the spec can be worked out. Until the inconvenience of having subtle technical conversations with someone twelve time zones away becomes negligible compared with a face-to-face conversation, local programmers will have an advantage over overseas programmers. (If the boss is overseas, of course, things are different.)
And then compile it. That is to say, if you've written your spec sufficiently precisely, then it _is_ code, and will compile, thereby sparing the need to hire programmers. The reason that you need programmers is that you haven't written the specs specifically enough, usually because it's essentially impossible to specify (many kinds of) software that accurately a priori.
Furthermore, and on this point I think we agree, there needs to be a fairly wide channel of communication between the engineer and the product manager exactly so that ambiguities in the spec can be worked out. Until the inconvenience of having subtle technical conversations with someone twelve time zones away becomes negligible compared with a face-to-face conversation, local programmers will have an advantage over overseas programmers. (If the boss is overseas, of course, things are different.)
> If it takes 100 hours in PHP, then people will start asking for 20 hours in RoR. And maybe now not everyone knows RoR, but those outsourced developers will pick it up if they have to. They will pass the cost savings on as well. And yet again, we're back into this cycle of code and applications as a commodity
The author of the piece addresses this. He's not claiming that outsourced developers can't learn Ruby/Python, but that by hugely reducing the time/cost to build an application, an X% savings is much smaller than it would be in Java. So if you save less, it's not worth the risk of outsourcing.
The author of the piece addresses this. He's not claiming that outsourced developers can't learn Ruby/Python, but that by hugely reducing the time/cost to build an application, an X% savings is much smaller than it would be in Java. So if you save less, it's not worth the risk of outsourcing.
Don't you have to have an iphone and a newish mac to develop for the iphone?
That barrier will keep costs high because not many 2nd or 3rd world programmers have access to these tools.
That barrier will keep costs high because not many 2nd or 3rd world programmers have access to these tools.
Not really. The outsourcers aren't using a dung powered recycled PC. The ones I have worked with have had hundreds of programmers, much larger than the companies I was working for. Usually they already had the hardware needed or could get it quickly.
Code has become a commodity.
Coding in general is now a commodity. Coding combined with specialized domain knowledge is not.
Coding in general is now a commodity. Coding combined with specialized domain knowledge is not.
"The only way to beat outsourcing is to be creative."
Why can't someone in India be creative?
Why can't someone in India be creative?
I love Rails and will agree that it boosts productivity tremendously, but if you cut out the 80% of your time you spend on gruntwork, you'll find that 80% of your remaining time is spent on gruntwork relative to your increased capabilities.
Which means the economics of "OK, outsource the gruntwork!" still make sense.
I have a RoR website which is probably pushing 1,000 lines these days. (1,000 lines in Java will, maybe, get a single page mostly done at the day job.) It blows away my day job in terms of functionality. You want to know what about 800 of those lines look like? Grunt work. (Validation that a user has a name and email address? Takes 1 line... 1 line of grunt work. Verifying that anyone using these 27 actions is an administration? 1 line... of grunt work. Implementing a search function for lost registration keys? Four lines... of grunt work. etc)
Which means the economics of "OK, outsource the gruntwork!" still make sense.
I have a RoR website which is probably pushing 1,000 lines these days. (1,000 lines in Java will, maybe, get a single page mostly done at the day job.) It blows away my day job in terms of functionality. You want to know what about 800 of those lines look like? Grunt work. (Validation that a user has a name and email address? Takes 1 line... 1 line of grunt work. Verifying that anyone using these 27 actions is an administration? 1 line... of grunt work. Implementing a search function for lost registration keys? Four lines... of grunt work. etc)
The point is that at a certain point writing the code gets easier than writing a spec.
Lets say you outsource this site, and you send a spec to the developer the spec looks something like this: 1) These 27 actions should only be used by an administrator. 2) All users must register with a valid looking email and choose a username.
Every one of those would still take one line, wouldn't it be simpler to just code the damn thing yourself???
Lets say you outsource this site, and you send a spec to the developer the spec looks something like this: 1) These 27 actions should only be used by an administrator. 2) All users must register with a valid looking email and choose a username.
Every one of those would still take one line, wouldn't it be simpler to just code the damn thing yourself???
Test driven development might help here. The test cases you write will act as spec, ensure quality of what they deliver and will also enable further development. You have not wasted your effort.
"(Validation that a user has a name and email address? Takes 1 line... 1 line of grunt work. Verifying that anyone using these 27 actions is an administration? 1 line... of grunt work. Implementing a search function for lost registration keys? Four lines... of grunt work. etc)"
This doesn't make sense as a definition of "grunt work" to me. These are more like business process rules or requirements. And 1 line or 27 lines or 4 lines of code sound actually more efficient to me than the corresponding English, mock-ups, etc. needed to specify the documentation for them.
In other words, it probably takes you much less time to write those lines of code than it would take to describe the required functionality unambiguously to someone living across an ocean from you.
This doesn't make sense as a definition of "grunt work" to me. These are more like business process rules or requirements. And 1 line or 27 lines or 4 lines of code sound actually more efficient to me than the corresponding English, mock-ups, etc. needed to specify the documentation for them.
In other words, it probably takes you much less time to write those lines of code than it would take to describe the required functionality unambiguously to someone living across an ocean from you.
Actually, more important to the deteriorating economics of outsourcing: the dollar is down substantially since 2002.
http://futures.tradingcharts.com/chart/US/M
http://futures.tradingcharts.com/chart/US/M
Couple that with the rapid wage inflation in India and you have the situation pretty much every programmer knew was going to happen sooner rather than later.
All I can read from this article is US developers are skilled and expensive, while non-US developers are non-skilled and inexpensive..
I might agree with expensive/inexpensive but who says US developers are more skilled than others? On what grounds, study, statistics can anyone claim that?
I might agree with expensive/inexpensive but who says US developers are more skilled than others? On what grounds, study, statistics can anyone claim that?
Even if such statistics existed, they wouldn't be that helpful because it pretty much comes down to how successful each company is when they outsource development work.
In my own experience, I've managed outsourced teams in China, Mexico, India and Argentina. While doing so, I've worked with some fabulous developers and also many not-so-fabulous developers. I've also hired more than my share of engineers in the US and the fabulous:not-so-fabulous ratio actually ended up being pretty similar.
The main thing that local developers have in their favor is they get to partake in the evolution of thought that takes place in any long term product strategy whereas remote developers don't have that advantage without the help of enlightened managers / dev teams.
The really good developers, however, wherever they are, are able to transcend even that challenge and contribute effectively to the product strategy. I've seen that happen in remote teams in all of the above countries and it's pretty cool to watch.
In my own experience, I've managed outsourced teams in China, Mexico, India and Argentina. While doing so, I've worked with some fabulous developers and also many not-so-fabulous developers. I've also hired more than my share of engineers in the US and the fabulous:not-so-fabulous ratio actually ended up being pretty similar.
The main thing that local developers have in their favor is they get to partake in the evolution of thought that takes place in any long term product strategy whereas remote developers don't have that advantage without the help of enlightened managers / dev teams.
The really good developers, however, wherever they are, are able to transcend even that challenge and contribute effectively to the product strategy. I've seen that happen in remote teams in all of the above countries and it's pretty cool to watch.
The main thing that local developers have in their favor is they get to partake in the evolution of thought that takes place in any long term product strategy...
Yep, that's it. It's not that the people are all that different. It's that a person twelve time zones away is a lot harder to communicate with than a person living next door. Especially if they're not from the same culture.
The cultural and distance barriers aren't impossible to overcome. But they are a handicap.
I used to work for a semiconductor company with a substantial factory in Malaysia. I'll never forget the first time I took the long, long flight to meet the engineers there. It was like removing a blindfold. You got into the factory with those folks and suddenly all their problems -- which had seemed so obscure over those damned conference calls -- became clear, and their personalities snapped into place, and you could start getting things done.
Yep, that's it. It's not that the people are all that different. It's that a person twelve time zones away is a lot harder to communicate with than a person living next door. Especially if they're not from the same culture.
The cultural and distance barriers aren't impossible to overcome. But they are a handicap.
I used to work for a semiconductor company with a substantial factory in Malaysia. I'll never forget the first time I took the long, long flight to meet the engineers there. It was like removing a blindfold. You got into the factory with those folks and suddenly all their problems -- which had seemed so obscure over those damned conference calls -- became clear, and their personalities snapped into place, and you could start getting things done.
From my experience the cultural one is much worse then the distance one. Also timezone is another distance related factor - far away but similar timezone means more collaboration.
I am currently having a similar experience. I've assembled a young and talented software development team here in Mexico, but the rest of the company (sales, QA, production, etc) is in California. I do not think they are aware of the our capacities and we do not understand where they want us to go. I feel out of the creative process of the company, but we are the ones who actually have the skills (programming) to take it there. So we are stuck doing what we are told to do.
My experience with several Indian teams at different companies bears out the article. They didn't have the same level of education that a developer gets at a good US engineering/CS school. It was more like at a JC level, a few months of Java then turned loose on the clients. The ones I worked with had several years of work experience, but not the depth of knowledge that one would expect from top notch locals. A lot of the savings was lost because we had to manage them more closely with a local liaison and daily code reviews.
OTOH I worked with a Ukrainian outsourcer that had very talented, well schooled, professional, and productive developers. They were also fairly expensive at $40/hour. Good, but not much cheaper.
OTOH I worked with a Ukrainian outsourcer that had very talented, well schooled, professional, and productive developers. They were also fairly expensive at $40/hour. Good, but not much cheaper.
Yea, that may be true. But I think most large companies in the U.S end up hiring average developers. Seems to me they have a hard time distinguishing who is talented and who is not. They also have a bureaucratic structure that does not allow the talented people to make the decisions and it becomes harder to retain the talented developers.
You probably worked with one of the big outsourcing body shops. The average developer anywhere in the world has a poor CS education, and this is the reason why Mr. Papadimoulis' site exists. I know folks who work for the Googles, Microsofts, Yahoos and the like in India and I find it hard to believe that the guys who write the JScript.NET compiler, or Windows Live Messenger don't have a CS degree. Clearly, you need to get over your bias.
Your $40 number seems grounded in reality though. I've never worked in the outsourcing business, but Ravi claims about $40 is what you need to pay for a good coder. [http://ravimohan.blogspot.com/2007/05/faq-from-my-mail-box-1...].
Your $40 number seems grounded in reality though. I've never worked in the outsourcing business, but Ravi claims about $40 is what you need to pay for a good coder. [http://ravimohan.blogspot.com/2007/05/faq-from-my-mail-box-1...].
"I might agree with expensive/inexpensive but who says US developers are more skilled than others?"
I would suggest it's more that the highly skilled developers in, say, India are not cheap enough to make the outsourcing worth it. Here's a WSJ article making that argument:
http://online.wsj.com/article/SB118342455118256110.html
"Last year, Mr. Shah paid his engineers in India about half of Silicon Valley levels. By early this year, it was 75%."
I would suggest it's more that the highly skilled developers in, say, India are not cheap enough to make the outsourcing worth it. Here's a WSJ article making that argument:
http://online.wsj.com/article/SB118342455118256110.html
"Last year, Mr. Shah paid his engineers in India about half of Silicon Valley levels. By early this year, it was 75%."
The seat value is usually as much as salary, if not more. I bet it still was less than 20% than in Silicon Valley (for sure at cost of social unrest and different infrastructure, but strictly money it is cheaper.)
There's the idea that highly-skilled developers who get things done will end up in the first-world if they are born elsewhere.
I'm glad I'm not the only one who was uncomfortable with that assertion.
Oh, these arguments make my head hurt:
>"The same 100 hour project with all the filler code obfuscated by Django or Ruby On Rails now takes 20 hours."
Ruby is so awesome that it simply saves 80% of your time? Really? You can't be serious. Yes, I understand the argument: If you remove all the fluff, you end up with the core problem, but I just can't believe that it's true.
>"Saving $800 over a higher skilled, more reliable, and more creative $80 an hour developer.[...] Its not worth $800, be happy with the $6,200 saved."
You should at least compare the 800$ to the 1600$, which is a saving of 50% - the risk might be higher, but the core problem is also in the "regular" project and you had no problem sourcing that out.
Seriously, these made up numbers are not helping. Maybe there is a truth to this argument, maybe not. But declaring you can get the same product for 20% of the price if you'd just use the right language is just wrong.
>"The same 100 hour project with all the filler code obfuscated by Django or Ruby On Rails now takes 20 hours."
Ruby is so awesome that it simply saves 80% of your time? Really? You can't be serious. Yes, I understand the argument: If you remove all the fluff, you end up with the core problem, but I just can't believe that it's true.
>"Saving $800 over a higher skilled, more reliable, and more creative $80 an hour developer.[...] Its not worth $800, be happy with the $6,200 saved."
You should at least compare the 800$ to the 1600$, which is a saving of 50% - the risk might be higher, but the core problem is also in the "regular" project and you had no problem sourcing that out.
Seriously, these made up numbers are not helping. Maybe there is a truth to this argument, maybe not. But declaring you can get the same product for 20% of the price if you'd just use the right language is just wrong.
Outsourcing can be hugely dangerous for startups. I have talked to the founders of several startups who were domain experts but not professional developers. They usually ended up with a product that they couldn't release. Part of the problem was that the founders were not sufficiently technically skilled to communicate their vision across the language and cultural barriers. Another was that they usually ended up with an unscalable MS stack. To be fair, that's pretty common, if you use less skilled US developers.
"During the Bubble, a lot of people predicted that startups would outsource their development to India. I think a better model for the future is David Heinemeier Hansson, who outsourced his development to a more powerful language instead."
-pg
http://www.paulgraham.com/vcsqueeze.html
-pg
http://www.paulgraham.com/vcsqueeze.html
This seems like a bit of a fantasy to me.
The notion that a significant use of java in enterprises is to churn out large numbers of small CRUD applications on brand new database schemas (which is really the only place such huge productivity boost is possible) is naive. In fact, often it is about internal interfacing between legacy systems with horrible, gigantic and contorted schemas that are near impossible to map into such frameworks and thus might actually turn out less productive since things like ROR are built on a whole lot of "assumptions" about what the system looks like that explode on you all over the place when it doesn't.
If there's a turn around in outsourcing then I think it's more to do with the costs of prior projects coming home to roost and changing the perception of it and / or the cheaper USD.
The notion that a significant use of java in enterprises is to churn out large numbers of small CRUD applications on brand new database schemas (which is really the only place such huge productivity boost is possible) is naive. In fact, often it is about internal interfacing between legacy systems with horrible, gigantic and contorted schemas that are near impossible to map into such frameworks and thus might actually turn out less productive since things like ROR are built on a whole lot of "assumptions" about what the system looks like that explode on you all over the place when it doesn't.
If there's a turn around in outsourcing then I think it's more to do with the costs of prior projects coming home to roost and changing the perception of it and / or the cheaper USD.
1: Outsource Django/RoR work
2: The 48-minute work week
3: Profit!
2: The 48-minute work week
3: Profit!
"Even the skill difference won’t be a risk. A low skill developer will be able to churn out 80% of the project in the same 100 hour time frame as a skilled one."
I thought this notion was quashed a long time ago. The author seems to suffer from a form of myopia where the only development he can see is web development.
I thought this notion was quashed a long time ago. The author seems to suffer from a form of myopia where the only development he can see is web development.
[deleted]
[deleted]
TFA doesn't explain what prevents outsourcing django and ruby on rails.
I think the answer may be... nothing.
Personally my approach is to do the bulk of the webev yourself and outsource stuff like graphic design, research, maybe some simple press release writing.
I think the answer may be... nothing.
Personally my approach is to do the bulk of the webev yourself and outsource stuff like graphic design, research, maybe some simple press release writing.
Easy. Outsourcings general return is something along the line of:
Cost Saving = .5X-R
Where: .4 is the factor that given programmers are cheaper. (So I'm assuming that your third world Programmer is half the price of your first world one) X is the total number of hours / days for the project *Note the implicit assumption here that all programmers are created equal) R is the risk factor. Harder communication, Cultural barriers, etc.
So for smaller values of X (say when you're using django not php) - then your expected return goes down. (And the overall influence of the Risk factor goes up - namely it could be cheaper keeping it first world)
Cost Saving = .5X-R
Where: .4 is the factor that given programmers are cheaper. (So I'm assuming that your third world Programmer is half the price of your first world one) X is the total number of hours / days for the project *Note the implicit assumption here that all programmers are created equal) R is the risk factor. Harder communication, Cultural barriers, etc.
So for smaller values of X (say when you're using django not php) - then your expected return goes down. (And the overall influence of the Risk factor goes up - namely it could be cheaper keeping it first world)
A good explanation on why it is harder to outsource Django or RoR development is because it's so close to outsourcing the conception of the application. There are things you want to do in-house.
Uh, sure it does, near the end.
Some bean counters will be tempted to take it a step further. Why not outsource Django and Ruby On Rails work to low skilled low price developers? Its not worth the risk.
Some bean counters will be tempted to take it a step further. Why not outsource Django and Ruby On Rails work to low skilled low price developers? Its not worth the risk.
Translation: "I am wearing blinders."