Farmsourcing: Part I
For the past six months I've worked in New York from Saint Paul (near Minneapolis) for an enterprise size company. They have offices in pretty much every country I can think of. During that time I've been working to get them up to speed with Ruby on Rails. This has included getting their outsourced offshore team up to speed as well. What I want to do is share some conclusions I've made from this experience. I gave a talk about this at Minnebar but wasn't able to discuss everything and hope to do so here. What I want to talk about is:
- Why enterprises are outsourcing
- How outsourcing to an offshore team fails them
- Why farmsourcing is better
- How Ruby on Rails seals the deal
I use to make fun of the enterprise. That is until I gained a deeper understanding of them. Truth is, they're in a rough spot and it's this difficulty that sends them outsourcing to an offshore team. It hasn't been my experience enterprises desire to do this. They’re not ignorant of the problems this has. They're just often left without a choice. Most enterprises have a large backlog of projects for a large number of users. On top of this, enterprises also have problems finding talent especially when trying to compete with benefits like free food, flexible hours, working from home and the chance to make it rich in options that many startups offer. Most daunting to an enterprise though is an increased frustration of users. Users expect their internal apps to work like external apps. Users want their intranet to work like Facebook and their messaging to work like Twitter. Given these difficulties, enterprises look for an escape. They realize their developers can’t make it happen in time. Not because their developers aren’t capable (though quite a few are indeed incapable) but because they're so busy just making what already exists just work. Add to this the need to control the bottom line and impossible becomes a real way of summing up the problem. This is why the escape enterprises often go for is outsourcing to an offshore team.
The idea is outsourcing to an offshore team will allow an enterprise to work some projects on the backlog while keeping costs down. Notice I didn’t mention anything about quality. That's because when you pick outsourcing you also pick to control time and scope and leave quality to the outsourced developers. The real failure of outsourcing firms is ignoring the fact that they are responsible for quality. Of course there are other problems with offshoring like:
- Timezone Issues
- Poor Communication
- Most use old technology which often result in delivering old technology
- Desire to do what ever the client asks even if it doesn't make sense
- Lack of talent - no mentoring
- What is the last programming language/API you learn?
- What programming blogs do you ready daily?
- Who do you ask when you have a question on code style? Who does that person ask?
- What are two or three bad coding practices?
- Why is testing important?
Quality is not important because most offshore outsourcing firms see programming as manufacturing and not as craftsmanship. They believe two teams working off the same requirements will result in the exact same application. This thinking is why offshore outsourcing often fails. Quality is ignored in favor of scope and time resulting. So when enterprises finally get the application it only works so long as you click on the right things in the right order and don’t ever try to add a feature, modify a page or upgrade a component because the application was manufactured and not crafted.
I don't think this way and everyone at Minnebar doesn't think this way. In fact the midwest as a whole doesn't think this way. For us it's about crafting software, not manufacturing it. For this reason I suggest enterprises Farmsource which I'll talk about in my next post.
