[LRUG] First post (about managing remote developers) [OT]

[Sidu Ponnappa]

Ryan,

One of the pieces of advice we give all prospective clients who are
non-technical is "Get a technical partner whom you trust and who can
evaluate the code being produced." You need someone you trust to vet
the work being done.

Working with remote devs is tough enough without also being unable to
judge the quality of work produced. Of course, the problem with this
model is that if you choose the wrong partner, you're back to square
one, but "Quis custodiet ipsos custodes" so what can one do?

As a Ruby consultancy, we'd examined this problem in some detail and
then written a blog post about how we'd try to look for an offshore
vendor if we ourselves had to[1]. But there's no way around having a
trusted, qualified person fill the CTO/VP Engineering role in your
business.

Best,
Sidu.

[1] http://blog.c42.in/identifying-good-offshore-ruby-and-rails-vend

On 29 June 2012 09:52, Ronny Ager-Wick <ronny at ager-wick.com> wrote:
> Ryan, hiring remote developers is a mine field, as many will tell you. Some
> developers, regardless of location, are extremely good, but not everyone. If
> you're unlucky, you may spend more money getting less done than you would
> hiring a local developer. Unfortunately though, although the proximity makes
> it more likely to work out, even that is not a guarantee for success.
> From my experience (which includes managing a number of developers, most of
> them great, but far from all), working with people you don't know yet, a
> short feedback cycle is essential. For example, you could ask for a list of
> things they plan to do the next day to be sent to you at the end of their
> working day, as well as a list of things they accomplished that day.
> Comparing the to-do list from yesterday with the accomplished list today
> should give you an idea of whether something is happening. The principle is
> similar to scrum, but of course modified to fit the situation.
> You should also have access to their git repository (assuming that's what
> they use - normally it is), so that you can pull (download) the changes in
> the code whenever you want. Insist on pushing code at least daily (temporary
> development can be pushed to a separate branch). If you don't know how to
> use git, learn at least enough to download the latest changes (git pull),
> review the log (git log), and see what changes has been done on each commit
> (every time they add new code). The last bit can be done with git diff, but
> you may benefit from using a graphical program for that, such as Qgit (I'm
> sure there are many others, and it may not work on other platforms - I use
> Linux). If you have doubts that they're actually delivering much, at least
> you can see for yourself what code has changed. Please note that programming
> high level languages is more about thinking than typing, so a low character
> count is not necessarily a proof that they do almost nothing. But a 0
> character count many days in a row almost certainly is :)
> You should also use a task management system, which allows both of you to
> comment on tasks and allows the developer(s) to indicate what they're
> working on and what's finished. You do have defined tasks (stories,
> features, ...), don't you?
>
> Some developers will likely react to this level of micro-management
> (although it's not really management, as they tell you what they will do,
> not vice versa - micro-monitoring maybe). I will have to warn you that while
> applying rules and regulations for how work should be done probably will
> scare away a large number of the less desirable people, it is also likely to
> scare away the best ones (at least if you throw the rules in their faces as
> soon as you meet). I'd try first, like you already did, to see if they can
> manage without your regime.
> No situations and no developers are exactly the same so there may be a
> number of reasons for them refusing to follow this scheme, or for agreeing
> but later on simply ignoring it. It could be that they know they would be
> caught not doing much, but it could also be that they are so experienced
> with self management that they find this degree of monitoring unnecessary
> and annoying. Just like Ruby, both control and freedom are double edged
> swords (although Ruby is more like a chain saw apparently).
> From my experience though, a lot of good developers impose a similar routine
> on themselves anyway and may even suggest it to you, as well as imposing
> rules on *you* to make sure you're constantly in the feedback loop and they
> don't have to stop work because of lack of information from you.
>
> It's a difficult balance - software development management is not as easy as
> it seems... Besides, if there was a solution that worked in all cases, I'm
> sure you could just google it and find the fool proof answer right away :)
>
> I wish you good luck!
> Ronny.
>
>
> Ryan Kalish wrote:
>>
>> Hi All
>>
>> This is my first message. I've heard great things about this community.
>>
>> I'm trying to launch a ruby based web startup, currently bootstrapping
>> an ecommerce idea which I believe can be highly profitable soon after
>> launch. I have employed a freelance rails developer based in Pakistan
>> through Odesk. He has been working for six weeks but progress has been
>> slow. I am not a developer so its difficult for me to know if I'm just
>> being impatient.
>>
>> I would be very interested to meet with London based rails developers
>> to discuss the project, look at what this guy is doing and maybe find
>> someone to work with on this.
>>
>> Please get in touch!
>>
>> Ryan
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
>>
>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org