[snorkel]

From my experiences outsourcing saves money but costs velocity. There is much time spent creating detailed specs, clarifying the specs, reviewing delivered code then immediately demanding key improvements made to that code, replacing subpar developers, pinging developers that have gone AWOL, and all of this happening with the usual timezone delays. Sometimes its faster to write the code yourself than it is to create painfully clear storyboards, wireframes, or demand yet another rewrite.

To avoid these hassles you have to spend a little more money to include a local manager to drive the outsourced team and be responsible for their delivery.

Honestly I get the sense that people who are happy with outsourced code are either unusually lucky to have found a highly skilled and responsive outsource, or more often they just not technical enough to judge the technical quality or the timeliness of what they are paying for. They are happy with the shiny car the outsourced team made and they can't realize the engine compartment is an absolute mess.

[dj_axl]

> or more often they just not technical enough to judge the technical quality or the timeliness of what they are paying for.

Anecdotally, this is the case. I've heard of or worked for three 400+ person companies that outsourced. Two of these companies had metrics/standards where they could actually measure code/work quality. One of these companies did not. The two that were able to judge were not happy with outsourcing and stopped outsourcing after a 1-2 year trial period. The one that seemed to only be aware of the short-term cost savings without being aware of the long-term code debt, they were perfectly happy. Different strokes for different folks, whatever floats your boat.

[byoung2]

There is much time spent creating detailed specs, clarifying the specs, reviewing delivered code then immediately demanding key improvements made to that code, replacing subpar developers

One could argue that this time would be well-spent even if your development team is in-house. The convenience of having all of your developers sitting in one room with you often leads to laziness and sloppy project management. When the customer service guys can approach an in-house developer immediately with a bug a customer reported, sometimes the bug gets fixed, committed, and deployed right away with no documentation. This makes for a great experience for that customer, and management can pat themselves on the back and call their team "agile" but imagine the alternative scenario.

Say that customer service rep has to create a detailed bug report with screenshots and steps to reproduce the error, and in the middle of the night (because of timezones) your outsourced dev fixes the bug and completes a post-mortem to close the ticket before committing and deploying. This leads to more organized processes, better documentation, etc.

[swombat]

That's exactly the point snorkel is making. You can get all that documentation, but that costs velocity.

For an early startup, velocity is way, way, way more important than clear documentation. When you're sitting with a rapidly shrinking runway and no viable business model, writing a spec, post-mortem, or documentation for a bug is a total waste of your precious, limited resources, like doing lunges when you're running out of air.