PS: someone said something insightful, but for some reason deleted it, along the lines of "this will pinpoint the problems of relying on unit tests for correctness". This is very true - one of the Interesting Problems such a project would need to solve is a set of tools to let users quickly design useful unit tests. I'm in no way delusional about automated tests not being able to prove correctness. But I'm not convinced mathematical correctness is all that often necessary, nor that this is a problem without a good-enough solution.
You could maybe do something based off of Git where the hirer pays to pull from contractors who have already glanced at the project and can jump in and add a feature, but the hirer would have to expose his business source code to everyone. The alternative is to expose it to less people and have them work on it for longer periods of time to deliver a properly integrated product which puts you back at a regular outsourcing service.
I don't think micro-outsourcing would work because productivity returns from the coder might not start taking off until after 1 hour.
Bingo. The role of the "programmer" then becomes to split a project into these micro-requirements, with minimal glue in between. This also yields a system of well-defined, loosely-coupled components... all things dear to my heart.
Even though I said ~1hr, I was thinking of one hour being the upper bound. If I can write testable specs in 3 minutes instead of code which would take 30 minutes to write/debug, I could increase my productivity at least an order of magnitude. But the point isn't even that, it's the kind of architecture one could create by "requesting" tons of custom built components throughout one's day, worrying about their whole structure instead of the bricklaying.
The thing is, I would want to 'retain' a few people for these tasks. For example, instead of one system admin, I would have four people who vaguely know my systems (have passwords, etc.) and if I offer an hour's worth of work, the first of the four to accept gets it.
Furthermore, if you are doing something like unit tests, you are dictating the system design. Then it is really just up to someone to fill in the blanks, which in typical software (say a typical web application) is trivial to do.
The only place I could see this working is where there is a simple input/output set. Something along the lines of a unix binary like sort or uniq. However, I'm not sure there is much outsourcing needed along those lines.
For some reason, i get the feeling not a lot of startups prefer "hiring" remotely, or perhaps places like Elance are more suited for this.
I've worked remotely for 3 startups and i've grown to prefer it.
Please sir, may I have some more?
Established organizations have processes and they are established, nothing changes too quickly, therefore making it more feasible to leverage remote workers.
personally, even though i fully acknowledge the whole "work with us and share the energy/dedication/soul" thing, i'm most productive when i have the freedom to swap up my view/environment every day (which is something you can't really do too easily inside an office)... inspiration, or something, i dunno.
i think it also forces people to be more thoughtful about the way they communicate/interrupt each other, which is pretty huge.
It still amazes me the visceral reaction people have against remote working. This would be fine as a principle, if the same people did not also complain to me that doctors do not embrace technology. But given that our platform is designed for doctors and patients to work together online (including online consultations) it behooves us to practice what we preach.
I will give the following tips: - You need different habits to work online. In my case, I have a lot of experience in setting up teams to work together virtually based on all my previous IT projects, including writing software for medical students to share their education across hospitals using Palm Pilots, and migraiting 300 employees to use a wiki. I also worked as a management consultant in a company that took pride in working with 2,700 hospitals but without traveling to the hospitals - all research was through phone and email. - You have to teach the rest of the team these habits, few people know them already. For example, in a telephone conference, you have to explicitly laugh when you would have smiled, as you cannot rely on visual cues for bonding. - Make use of wikis and document every meeting you have, as you have it, with everyone seeing what you type as you type it. - my co-founders were either people I knew, or people I got to know in person through volunteer work I would ask them to do over coffee meetings before I asked them to join the company.
By far the biggest saving we have is time. It is not being cheap and cutting costs of office space, it is about slashing the time we spend on commuting and meeting, and I would definitely say that we would never have achieved as much as we did, as quickly as we did, if it was not for working virtually.
It's not that trivial, so I don't think that using some random dude from a freelancing site would be viable.
it was kinda weird that they gave me the freedom to basically build all the really important shit (ie: i got to pretty much lay the foundation and designed a bunch of distributed systems and algorithms as i went a long) despite me being the most junior member of the team, but it was all java stuff, plus i grew up doing flash/flex work.
i have a portfolio up at http://www.lzimm.com, not sure if i'm senior enough for you, but thought i'd throw that out there just in case :)
Great article (http://www.lzimm.com/nov2009/purpose.html), too!
Anyways, I'm kinda stuck on what I can tell you.
I basically built a bit of infrastructure shit that let us build all the pricing and billing logic at scale. So my role was more "low level" than what went on with the actual transaction processing, which I think was pretty typical. That said though, I'm sure that's not your question, which is more resolved around the economics at large, so even though I'm probably not supposed to talk about this, I don't really care:
- the entire gaming industry is struggling to make money in new ways (ie: piracy blah blah blah). - one way to do it is subscriptions (ala WoW), but i think most the big publishers are finding that its pretty hard to actually do that successfully (WoW is a pretty rare phenomenon) - the other big way to do that (online, at least) is the whole free-to-play thing, where you make money by letting people buy virtual goods and crap (ala all the facebook crap) - the thing is, when you get into games that people take seriously, you have to be careful about the goods you let people buy, because all of that shit can really change game mechanics, so you have to either: restrict yourself to selling things that don't mean anything, like avatars and crap; be very careful that if you do sell items that affect gameplay, not to build strange new equilibria, or more importantly, prematurely alienate players before you get to those equilibria in the first place; or (taking the approach that we were taking.. i think anyways, i got pretty fed up at this point because it seemed like they kept focussing on incredibly moot details), make it so that you can't buy an advantage that you can't get by just playing the game (ie: only letting people buy items that you can get through random item drops that reward gameplay as opposed to debits from your bank account)
i have no idea why i did that in bullet points.
furthermore, i have an incredibly bad sense of grammar right now, so i'm not sure if that even made any sense. drop me an email if you wanna chat more :)
--
edit: uhhg, i have to admit, this reply seems terribly uninsightful, sorry :(
Look at freebsd, apache *, webkit, and thousands other projects - they're growing up by the effort of hundreds of remote commiters, and managed somehow to follow the architecture agreements and the design decisions.
The idea is very clear - you cannot pay people on 'per hour' or even 'per line' basis - it works only for a full-time jobs where people are bounded by contracts, NDA, and other papers.
In contrast, in the open source world, people bound by idea, desire and the common effort, see the nginx project as an example.
But it is possible to pay for accomplished goals or milestones. Of course, you need to define the basic rules before - coding style, unit-tests requirements and so on.
So, if you like to hire people remote people, you need two things - idea and trust. Set up trac or code.google.com, write your ideas and requirements and pay for closed tickets/issues.
Update: To anonymous coward down-voters: It is better for everyone (even for you) to share your opinions instead of simply click the button. =)
The reason the other downvoters didn't respond was that there's no need to pursue this thread of communication further, as it does not really relate. It's cowardice in the same way not fighting the guy who cuts you off in traffic is cowardice.
And I don't intend to turn this into any kind of debate or anything. Just my two cents on why you got downvoted.