The answer is not screen-sharing, it's making everything an API. The remote worker is responsible for her API, and no one needs to know or care how it works as long as it does.
While I generally do favor service oriented architectures (and remote work), this is woefully short sighted.
Say the remote worker builds you a shaky RoR+MongoDB app, no scalability, no error handling, no tests, no comments. At least in the short run, it works - there are occasional outages, but the worker (remote or otherwise) does a great job keeping it going. Then the remote worker quits. What do you do?
Just because something is behind an API doesn't mean you don't have to worry about knowledge transfer, code quality, etc.
Okay, good points ;-) I may have overstated my case for emphasis; but I maintain that in general, an API is better than a library (there was an article saying just that some time ago on HN; can't seem to find it right now).
I wouldn't even go that far. "API" and "Library" are not distinct concepts. A library has an API - it's the set of public functions (ideally rarely changing) that you are supposed to call from external programs. It is beneficial if one developer can hide their work behind a simple interface with only a few access points (the API), but there is no compelling reason this should be json over http.
The real distinction between a network API and a library is that the network API allows users to avoid thinking about the hardware. The API provider is responsible for allocating hardware, the user need only send messages over the network to use it. I.e., buying hard drives is Amazon's problem, I just GET/PUT my files onto S3.
If the API isn't hardware intensive, this is pointless - you are adding network overhead (i.e., latency, network errors) for nothing.
That just opens another can of worms. Now every single application you either provide or use come with an integration issue attached.
I have read somewhere that was the Amazon way of doing thing but it was a costly investment. A costly technological investment. And even Amazon did it only at team level, not individual level.
I cannot imagine a 500 developers company being able to afford that without some serious competitive advantages down the line. If what I can see around here is any indication (medium size IT company in London), if you can afford not having people on site, there are better opportunities to take in Poland or even India than a small discount on a UK worker.
Unfortunately, a network API letting you mix and match languages still opens up risk from a rogue employee who uses something different than the status quo and then quits, leaving something unfamiliar that needs to be maintained.
What a demoralising (and grossly incorrect) way to look at work.
If your work can be reduced to such an API, then I'd argue that you can be replaced with a script. Most jobs, however, even today, are far more complex than that. As a very obvious example, culture is an extremely important aspect of building a successful business, and a person's contribution to culture is irreducibly complex and unmeasurable, and untameable to stating an API type contract.
I meant the remote worker builds and maintains an API, not that he himself is an API.
> culture is an extremely important aspect of building a successful business
Yes, maybe; but there are many businesses that are already built and that would benefit from treating some parts of their process as self-enclosed APIs.
I would go so far as saying many already do, without knowing it.
That only works if you can separate responsibility out to the extent that each person is responsible for a specific area of the code and works only on their designated area.
What happens in practise is that a feature or bugfix might require a large change to one part of the code and a much smaller change in another.
So the developer tasked with the small change will finish before the other. Now you have an idle developer and an overloaded developer holding the process up. If you have a process whereby the idle developer can't share some of the workload of the other you are going to have very inefficient development.
You also run into problems if one developer is on holiday , off sick or leaves the company since nobody else has ever looked at their code.
There's also a risk of bringing politics into re-factoring decisions. "This functionality should be part of your API".
