I asked a question on lines of code per hour and got torn a new one.  So my matured follow-up question is this:

If not lines of code, then what is a good metric by which to measure (by the hour/day/unit-of-time) the effectiveness of remote programmers?

In 16 years I've never actually found a workable metric of the sort you're looking for.

Essentially to be useful anything would need to be measurable, representative and ungameable (that is the system can't be played by clever developers).  There are simply too many variables within software development to make it measurable as piece work in this way.

The closest you get is progress against estimates - that is how many tasks are they completing within the agreed estimates.  The trick here is (a) getting good and fair estimates and (b) understanding where estimates have been exceeded for good reasons for which the developer can not / should not be blamed (that is something was genuinely more complex than anticipated).  Ultimately if you push developers too hard you're likely to find estimates gradually creeping up to a level where they're always met not because of increased productivity but because of padded timescales.  

Go the other way too much in terms of the estimates (reducing them to create pressure to deliver) and you create phoney deadlines which studies have shown don't increase productivity and are likely to have an impact on team morale (see Peopleware for more information).

But essentially I wonder if you're looking at a slightly false problem.  Why are remote programmers different to other programmers when it comes to measuring productivity?  How do you measure the productivity of non-remote programmers?

If it's about not trusting them to work remotely then that's basically a wider trust issue.  If you don't trust them to work from home then you either need to establish that trust, not let them work from home, or find some way of satisfying yourself that they are indeed working when they're meant to be.
