Mosquito Mole Multiworks

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.

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 would like to propose a new term to describe a subset of programmers: BigMac Programmers. This term is reserved for those programmers intent on applying copious amounts of special sauce on their work. Examples of this special sauce include exotic caching strategies, esoteric firewall rules, custom database connection pooling and in general anything that has more lines of code then days in production without an error. Alternately stated, special sauce is anything that could be replaced with an highly downloaded alternative in less time then it takes to describe how bad the special sauce really is.

BigMac programmers should be avoided at all times as they will bring a cardiac arrest to your project. If you must work with a BigMac programmer or cleanup after them, bring boots; for a BigMac programmer has likely produced a large amount of excrement as they’ve gorged themselves implementing every search result Google provides for their particular problem at hand.

Some reports suggest BigMac programmers can be converted but these claims have never been substantiated. It is therefore suggested BigMac programmers be fired and other programmers alerted to their presence. To alert others it is recommend to provide the BigMac Programmer a certificate noting their BigMac Programmer status. They will think it’s in recognition of their advanced skills and post it proudly on their wall while in truth it’s an early warning system for others in the area.

I will be speaking at the MnIPS Open for Business: Best Practices in Open Source conference tomorrow. My focus will be on how best to work with the Open Source community. Hopefully I'll cover that topic well and also cover how to use the Open Source community to get your work done. Until tomorrow, here is a nice video of Zed Shaw talking Open Source community.