11

I've been hiring several developers from different places around the world. It all goes well, but I see that some of them are abusing my polite overlooking too much lately.

They are all hired for a full-day. However, I see that after 5 hours in a day, not much has been done.

I am considering to develop a software that will take a screenshot of the computer screen every 1-5 minutes and upload it to my system. However, this is going to the extremes.

How do people usually manage remote developers?

Gajus
  • 342
  • 1
  • 11
  • 61
    Consider paying them to solve problems instead of working X hours. –  Mar 12 '12 at 11:46
  • 5
    See also: http://programmers.stackexchange.com/q/110487/6605 – Arseni Mourzenko Mar 12 '12 at 11:52
  • @MainMa, that rises a valid point. – Gajus Mar 12 '12 at 12:07
  • 2
    How can you mandate that the developers run your homemade privacy intruding screenshot software? Unless it was in the contract beforehand, or you supply the hardware to the developers this is a massive breach of privacy. Who is to say that their dev machine doesn't double as their home browse machine? Or how can you guarantee that you won't take screenshots during off hours? But if you do go this route, be sure to install the key logger software to get the whole package. – Dylan Yaga Mar 12 '12 at 18:37
  • @Guy You should amend your question to include a required coding standard (as per your comment to PaulTomblin ). It seems like you want a combination of results delivered + results coded to your standard. You need to add it into contract/job description that Results + Standards met = pay. Add deductions/bonus' for really bad/good results, IMO. – WernerCD Mar 12 '12 at 18:57
  • I'm a freelancer. I would NEVER accept a job from someone who requires me to install software to make a screenshot every few minutes. Besides, how would this help? Programming is not just typing in source code! – Jesper Mar 13 '12 at 14:01
  • "I see that after 5 hours in a day, not much has been done.": Sounds about normal. There is also variant B: I see that work is done just the last 5 hours in a day – phresnel Feb 20 '19 at 14:43

9 Answers9

45

You hire honest programmers, and you (in consultation with them and possibly other honest programmers as a reality check) set reasonable goals in short time lines. If they don't meet the goals, fire them. If they do meet the goals, then it shouldn't matter to you if they play solitaire for 2 hours straight while they're clearing their minds and mulling over a problem.

Paul Tomblin
  • 1,949
  • 1
    That's not necessary true. That's actually the example that I don't want my company to follow. Why you might ask. Because during my contractor years I've seen plenty doing business this way. The developer writes the code to make sure that it works (This is where your model ends). I want the developer to perfect the code, make sure that code is most efficient and any stupid mistakes are put off the way (much harder to keep an eye after), i.e. if you are paid for 5 hours, you work 5 hours. – Gajus Mar 12 '12 at 16:15
  • 27
    @Guy: If you want them to routinely exceed the goals you set, then should set different goals. – Jonas Mar 12 '12 at 16:22
  • 4
    @Guy what you are asking for sounds more like some performance requirements and a warranty – jk. Mar 12 '12 at 16:39
30

Screenshots seems counter productive. If it comes to that, you're in trouble.

The ideal is to have tangible milestones, and check their progress against them. If you can't get your money's worth on the milestones based on the amount of time you have to pay to get them, find other help. If you can't create the work at this level of detail, and don't know if you're getting ripped off, it might be inappropriate to source the work remotely. You could introduce a system of competitive bidding for the work, but if you can't detail what's needed at a low level, can you tell what the code quality is?

In general outsourcing and remote work should be about buying results, not buying time. Otherwise, as you've found out, the trust breaks down.

MathAttack
  • 2,766
  • 9
    +1 for "buying results, not buying time." – Eric King Mar 12 '12 at 17:16
  • 2
    Be generous with the schedule (if you can), and pay them based on the deliverables, so they don't have to freak out if there are unexpected bugs that take a lot of time to squash. It then shouldn't matter to you whether they fill the extra time by working another non-competing contract job or if they fill the extra time by playing solitaire. – Ken Bloom Mar 12 '12 at 23:51
  • 1
    What happens when they serve their "results" with a side of horrendous spaghetti code? Nobody wants to do future work on that project, not even the original developer. But on the bright side, you did get your "results." – Buttons840 Mar 15 '12 at 16:05
  • 1
    Results include quality if code. Hard to quantify, but you can get crappy quality paying for time too if you don't know what to look for. – MathAttack Mar 16 '12 at 01:52
14

What you want is called a contract. The contract say what they have to deliver and when, and what you have to pay and when.

As simple as this. Everything else would be dramatically counter productive. It will break confidence between you and the freelancer. If you want to closely look at what people are doing, then consider hiring in your office.

deadalnix
  • 6,013
  • 2
  • 31
  • 27
  • Insisting on a contract is all well and fine, but I don't think I know of any big software that was actually delivered on target. Overruns by a factor of 2 or 3 seem to be very common from what I've seen. – apoorv020 Jul 15 '12 at 13:58
  • It is, as well as it is to change specification at the dumbest possible moment from the client. This is why the contract is important. Having a contract don't prevent you from amending it later on if something change according to the original plan. – deadalnix Jul 15 '12 at 17:44
7

They either produce enough code for what you are paying or you find someone who can. If they pounded on their keyboards and mice for 10 hours a day and produced garbage, are you still going to keep them just because you're paying them for 8 hours?

Set demands and get agreed upon deadlines. If you can't agree, hire people who will. You're a programmer and should be able to spot if they have hit legitimate obstacles or not.

JeffO
  • 36,816
3

I would create an excel sheet with a break down of each feature.

The contractor should update this daily.

Each item should have a progression defined in terms of %.

When a feature is 100%, it should be ready for you to "sign off".

If an item does function as expected, then this item needs to be flagged and corrected.

Darknight
  • 12,199
  • 1
  • 39
  • 58
3

Do your homework first

You need to be comfortable with the people you are hiring, before you hire them.

At the point you are thinking of essentially spying on the people you hire, it is too late. I am an honest programmer, but I wouldn't work under those conditions (even assuming that they are legal). It's like when you cross the border - you might not be hiding anything, but they sure make you feel like you are.

Do background checks, get references, ask questions. Use reputable services. Make careful decisions, and then follow the advice in the other answers given here.

Wonko the Sane
  • 3,172
2

I have been working with Scrum lately and I can tell you. With this Agile methodology slackers has no room to avoid transparency. And also proves that you are being a good manager/leader dispatching them achievable tasks.

Rodrigo Asensio
  • 121
2

Are you paying for results or time? If you're paying for results, then it's none of your business how long they take to achieve those results. If you're paying for time and you don't think they are being honest about their time, let them go and find someone else-if you can't trust them, what good are they?

If you provide the environment, recording is an option, but you'll need to inform them first, which will give them the ability to fake it. How long does it take them to search for the answer to a problem? Reading offline resources, simply sitting and thinking? If they aren't honest, all you're going to do is spend a lot of your time getting inconclusive results. If they are honest, you're probably going to offend them and they'll move on. Either way, they are gone.

jmoreno
  • 10,853
  • 1
  • 31
  • 48
1

What about source code repositories and you require them constant committing. Small, atomic commits: "commit early, commit often." Utilize DVCS's features (branches, tags) to commit stuff that isn't meant to be included in the final product.

That way you can have pretty good idea what is done, what has to be done and so on.

mike3996
  • 197