I've been thinking about an interesting model for working remotely - something that might be called micro-outsourcing. The paying party provides a set of automated tests (like unit tests, but with speed/space constraints) and a price. Coders submit code which runs against the tests. If it passes, the payer can pay their predetermined amount to buy the source. The idea is to make the turn around fast enough that it makes more sense to program even simple code by "micro-outsourcing" dozens of ~1 hr pieces every day. This way, you could get ~50 hours of code written in a day's time while still keeping the entire architecture of the system in your head.
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.
I'm not sure how this would work on closed-source projects. Coders would need to see the existing code that others have written to get anything done, 1 hour of coding could be 45 minutes of grokking how your system is setup and 15 minutes of work. It seems like "micro-outsourcing" would only work for micro-requirements.
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.
It seems like "micro-outsourcing" would only work for micro-requirements.
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.
This is something I would love, for both coding and system admin tasks.
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.
My issue with this idea is that the process of creating a complete set of tests is that the effort involved in creating them is likely greater than the actual coding.
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.
Very close. Unless topcoder has changed since I last looked, the big difference is the turnaround time - one on the order of minutes or hours, not days or weeks.
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.