Outsourcing Revisited And No One Is Safe
Published Nov. 11, 2017
The recent article Outsourcing Killed By Django And Ruby On Rails has caused as much proper debate as it has blind controversy. The feedback provided by readers here as well as other sites like Y Combinator and Reddit have brought up some good points. If I had to write the article again here is what I would change…
Drop the US as an example, define outsourcing relative to any geographic point. If you’re in Germany as US developer would be considered offshore. The same problems and the same numbers would apply.
Remove references to quality, focus on incurred cost of outsourcing. Quality is difficult to quantify and easy to debate. When frameworks like Django or Ruby On Rails effectively reduce core project development (coding) significantly enough, periphery project costs grow in proportion. Communication can become the bottle neck, for example. A time zone difference of a few hours (8 – 12 in the case of US to India) means project decisions have a significant lag. Over the phone or email communications are not as effective as face to face time, especially with cultural and language differences. Even with highly experienced staff the cost of doing business time zones apart is higher than face to face.
Avoid the term “low skill”, and focus instead on the risk of hiring talent you’ve never interviewed face to face. There is a reason Ebay, Google, Microsoft, YouTube, and so forth interview people in person before hiring. The risk of making a bad hiring decision that will cost significant dollars down the road drops after a good interview. How does one interview an individual several thousand miles away with the same level of confidence? You can’t, hence a risk of outsourcing that can be avoided by hiring local, which is made possible by frameworks like Django and Ruby On Rails.
Place emphasis on cheap labor as the target segment. Of course there are expensive developers everywhere, there are also cheap ones everywhere. Here in the US we have both, same as India, China, and Germany. Point is you get what you pay for and the mantra around outsourcing (at least here in the US) is cheap. Its a brand that was crafted by the outsourcing companies, now its back firing. Bean counters think dollars not skills and in US corporations bottom dollar wins out more often than not. So chances are if a US company outsources to India, it will outsource to the lower bidder regardless of skill.
Write a whole paragraph about how it doesn’t matter that developers in India or anywhere can pick up Django or Ruby On Rails. The frameworks have marginalized development to a point where its not the selling point. Communications, coordination, risk, and schedule are now selling points. The risks in those areas only get worse with off shoring or outsourcing across time zones.
Reference some of the frameworks in Java, PHP, and Perl that came before Django and Ruby On Rails. Yes, there were others but none as successful. Why? Ask the developers of Django and Ruby On Rails, they figured it out. For the rest of us, the important question is what does it signal for the future of web development. I’m guessing the end of off shoring, at least for a while.
Emphasize that Python is not Django and PHP is not Cake. Too many comments came back giving metrics for Java vs. Python or inferring PHP is the same as Cake. The discussion is around Django (not Python) and Ruby On Rails (not Ruby). Python itself reduces some development and coding because its an interpreted language with no type casts. Django on the other hand is a collection of functions crafted for the sole purpose of developing web applications. There is a huge gap between the two, thats why the focus is on the effects of Django on outsourcing.
The original message holds. No matter how you dress it up or how much mud gets flung at it, Django and Ruby On Rails are killing outsourcing. There will always be jobs, and like many readers pointed out, good developers will always have them. The difference will be that they will come from down the street instead of the other side of the world.