Outsourcing on rentacoder

Outsourcing is a big topic and rentacoder.com is an established company already taking advantage of the trend to outsource projects or parts of projects. They cater for the small to medium businesses. I have used rentacoder twice so far, for two small sub-projects and I have decided to write in my blog about it.

There is a certain attraction towards outsourcing. The very idea of getting some help from someone else and shipping my product earlier than planned is very attractive. In every project there are parts that are tedious, not very attractive or require a lot of time but they must be done. These are the parts that it is so easy to convince yourself that you'd be better off outsourcing them to someone else.

At the same time there's an inherent fear that comes with outsourcing and losing control over certain areas of your code. While the attraction is obvious, here is a list of my three main fears when it comes to outsourcing.

1. Quality

I'm not sure how good the result will be and while I can set some clear goals for the project, I definitely need to check that the goals have been met. That means writing extensive acceptance tests, test plans and performing extensive manual testing. Again, I could outsource this task too, but then we'd be going recursive.

Quality is not only restricted to the functional aspect. It is also the quality of the source code, how maintainable it is, how extensible it is, etc.

2. Detailed specs

Outsourcing forces you to write very detailed specs. You have to cover even the most obscure corner cases, otherwise you might get back a lemon. If you want control over HOW not just WHAT gets delivered, then you will need to write design/architectural specs in addition to functional specs. You might even have to write code templates.

The risk here are obvious:

      a. Provide too little and they might come back with too little or too badly designed/implemented (funnily enough, it might be exactly what you've asked for)

      b. Provide too much and it will take you more to write specs than it will take you to do the work yourself

The positive side is that writing specs forces you to think about use cases, even obscure ones. You might discover flaws in your thinking and in your assumptions.

3. Source code leakage

Giving away your source code is always risky. You can sign NDAs as much as you want, but in a global world, you soon find out that you can't enforce NDAs easily, especially if you work with developers located in places like India or Russia.

The nightmare scenario is to wake up one day and find out a clone of your software, doing exactly the same thing, sold at a fraction of what you're selling it.