Ask YC: How should outsourcing be structured? | Hacker News Reader

Ask YC: How should outsourcing be structured?

9 pointsandreyf9 comments

Some comments from drinko's dilemma got me thinking... is there any way that outsourcing can be made to work, consistently?

What about a competent lead developer who designs the application and writes the unit tests, but outsources the small implementation details and bug scourging/research to outside developers?

For those of you who have had good experiences outsourcing, was there any such pattern?

View on HN

[I work in Bangalore, have worked in the United States, and have seen both sides of the outsourced projects]

"What about a competent lead developer who designs the application and writes the unit tests, but outsources the small implementation details and bug scourging/research to outside developers?"

This won't work. You can't really write unit tests separate from the implementation. The implementation and unit tests feed off each other.

"is there any way that outsourcing can be made to work, consistently?"

Here is what has worked, in my experience.

(1) Have a fixed bid AND milestone driven (where "milestone" is used loosely to indicate a "chunk" of business value and takes between a week to a month to code) project. Pay per milestone. At best you lose a couple of weeks worth of money.

(2) Hire a good developer in India/China/wherever. Work with him on the project with loose milestones. Talk for at least 20 minutes everyday (skype, etc). Once you gell, ask him to reccomend another, equally good developer. Build the team slowly.

Small fixed-price projects has been the key when I've done this. Anything too large, and the scope will not be apparent to the people you're outsourcing too. Also, I use google to search rentacoder.com bio pages and find someone who has already successfully done as close as possible to what I'm looking for, but for a different client. As Aneesh said, if they're good, keep them busy with new projects.

By the way, I think you can do larger projects if you play the role of business analyst, project manager, and also have coding skills. Basically, you chop the project into a succession of smaller documented projects. I think I could make this approach scale, if only I didn't dislike playing these other roles.

If you can figure out how to do this consistently for difficult, unpredictable projects, you're on to a winner. I don't know anyone who's managed that yet.

Big corporations make good use of outsourcing, but it tends to only work for projects that aren't essential/bleeding edge.

Also, a competent lead developer will only want to work with other competent developers, so that won't solve your problem. As a competent lead developer myself, I wouldn't bother working with "bad" developers because I can be more productive by myself than with them on board.

Here's a good article/story on the topic:

http://www.jaisenmathai.com/blog/2008/05/01/this-is-what-hap...

they failed faster, and they failed cheaper. it was doomed anyways.

I usually provide a TON of documentation to make the project as error-proof as I possibly can. Sometimes contractors don't like to think for themselves.

Agreed, think of the documentation as code and specify details as such.

Only one other thing, which is after you've documented to that level, go back and bold important stuff, add summaries, etc b/c some contractors eyes glaze over.

Quality of developers varies a lot when you outsource. Hire many for small tasks, and keep the best ones.

The lead developer needs to be on the founding team, needs to vet all the outsourced developers, and needs to design the app at a big picture level.

Reply on news.ycombinator.com