Farmsourcing: Part II

June 9th, 2008

In my last post I stated the real failure of outsourcing firms is ignoring the fact that they are responsible for quality. Most offshore outsourcing firms view software development as a manufacturing problem. I don't think this way though. You don't think this way. In fact the midwest doesn't think this way about software. Cray doesn't manufacture it’s compilers, it crafts them. DowJones doesn't manufacture it's systems, it crafts them. They're crafted by craftsmen using tools they have often built themselves. Quality is a focus.

Additionally the cost of living here is reasonable compared to either coast. I travel to New York often and stay in a basic room at the Waldorf Astoria in Midtown. It costs around $350 - $400 a month. For that same price I can get a two room suite at The Saint Paul Hotel. I get twice as much hotel here in Saint Paul compared to New York. The same is true for software development. In fact with raising prices in India year after year, the price difference per hour can be as little as $20 and as high as $50. Though on average it's around $25 to $35 and hour. That price difference is even less once you take into account soft costs. For example having only one hour time difference, common language, ability to meet in person cheaply (thank you SunCountry). By far the best benefit is talent though. Developers in the midwest are using the best and latest technologies, have access to a number of mentors, conferences and user groups. Did I also mention developers in the Midwest can produce nearly twice as fast as those in India. If this speed is included, developers in the Midwest are actually cheaper and of course, developers in the Midwest focus on quality.

This is the essence of what I call Farmsourcing. This combination of reasonable developer costs, developers that focus on quality, increased productivity and proximity to fields of corn. So how does it work? After all good talent isn't cheap. My solution, use unpolished talent, pay them lower wages, mentor them for 1 to 2 years and then get them a better job somewhere else. This solution has problems though - some similar to those India faces.

First I need to find a good source of unpolished talent. For that we have new CS grads from universities like the U, St. Thomas, Macalester, Metro State and so on. Let me qualify what I mean by unpolished talent. I define it as someone who understands the concepts but doesn’t know how to implement them.

Second problem is the lower wages. I pay anywhere from $20 to $40 an hour and most times closer to $25. Why would someone work for these lower wages? Let me ask you this question. Why would someone pay to go to grad school? Most likely because they want the final education that will set them apart. Well that's what I’m offering: grad school expect they don’t pay - I pay them. Here’s what I tell prospective employees: come work for me for one to two years, I'll pay you a decent but lower wage during that time. But I will also mentor you on everything from version control systems and continuous integration to project management and contracting. At the end of the one to two years you'll not only be able to get a job worth twice as much but I'll help you find it.

The third problem is how to actually mentor barely functional into quite good? Or put another way, how do you scale your team? I'm not going to go into the details of this since this process is our secret to success. But I'll say it's a combination of three things: The mentors, the process tools and Ruby on Rails. The latter of which I'll talk more about.

Rails really makes this happen. First, I can explain Ruby to someone in just a couple days. There isn't even a book they have to buy to learn it. Try that with C++. Second, Rails is very opinionated. So long as you do things the Rails Way life is easy. When you don't, things get hard. It acts like a warning light for newbies when they’re doing something they shouldn’t. I tell them, if it's hard, ask a mentor. Third, Rails is Ikea. It has darn near everything you need already so there is no need to build it. This is good for a couple reasons: it makes apps smaller so statistically there should be less bugs, you can produce faster because you don't need to build it, and all the code in Rails acts as a nice reference when you do need to build something yourself. Fourth, Rails has testing built in. You need tests when working with barely functionals. Fifth, there is no compile step in Ruby and thus encourages what if exploration which results in deeper learning.

Because of Ruby on Rails and Farmsourcing I no longer worry about the enterprise and every manager and CIO I talk with about Farmsourcing with Ruby on Rails worries less too. They also quickly find a project to try it out on. How big can Farmsourcing get? I’m not sure but what I do know is outsourcing is a $20 billion business and I’m not quite there yet. So if you have capital to invest so we can faster and keep up with demand or are interested in a job, please contact me.

Farmsourcing: Part I

May 12th, 2008

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
But the real problem I argue is quality. Don't believe me? Ask these questions of any developer working for an offshore outsourcing firm. (Note if they can answer them, keep them)
  • 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.

Speaking @ MinneBar

May 5th, 2008

I'm very excited to be speaking at MinneBar this weekend. If you don't know about MinneBar, show up and find out. It's the premier tech get together in Minnesota and a top rank event for the entire Midwest. People will be presenting on a wide number of topics.

I'm excited to present on talk titled: Outsourcing Rails: or How I Stopped Worrying and Love the Enterprise. This is something I've been thinking about for a few months but last week when I was in New York it finally clicked. It's taking a lot of work but this presentation is really coming together. I plan to cover why Ruby on Rails and the Midwest might just save the enterprise. I'll share my experiences with outsourcing Ruby on Rails to various parts of the world, what the large outsourcing firms are doing, why they don't get it and how the Midwest could destroy their business in months. You will not be disappointed with this presentation.

This presentation will be the start of many posts, articles and presentation about what I call Farmsourcing. Stay tuned. I plan to change the game.

 

I'm Matt Bauer and this is my blog. It's mainly about Ruby on Rails, Erlang and database development though other topics are also included. I code and write and hopefully you'll enjoy the reading.

 Subscribe in a reader

Search

Categories

Archives

Tags

 

My Books & Contributions