[LRUG] First post (about managing remote developers) [OT]
Ronny Ager-Wick
ronny at ager-wick.com
Fri Jun 29 23:26:12 PDT 2012
Hi, Artan,
I completely agree with you. As an independent consultant (or whatever
we should call ourselves now) I am also working remotely, and wouldn't
consider anything else. I also feel I'm more efficient and it's much
more practical, and family friendly, compared to being location bound.
Doing the kind of work we do should allow us to do it from anywhere we
please, and personally I feel there is little need for being place bound
like an old fashioned industry worker. Yes, I know there are some
exceptions (like pair programming and occasional interaction with
users), but that still doesn't justify 9-5 work, as far as I'm concerned.
As I mentioned in the original post, having a developer in house is far
from fool proof, but it tends to have a higher percentage of success. I
must admit, this is purely speculation based on hearsay though - maybe
I'm even wrong and it's just "traditional knowledge" that dictates that
as a fact. The reason I allowed this statement without collecting any
evidence, is again personal experience. Being in the same office makes
it a degree harder to slack off and do nothing, or sit for hours trying
to do a simple thing which could be done with a bit of help, maybe
because someone may open your door at any given time and ask what the
heck you're doing. It's harder to ignore that question compared to the
same by email. Also, if you deal with a remote developer and there is
little contact throughout the working day, and no or very long feedback
cycle, you may sit there thinking the developer went on holiday or
something - something a physical presence effectively eliminates :)
I can say this because I've been on both sides. In my early career I
briefly worked in house for two different - *very* different software
companies. And I've seen both great developers working in house, as well
as those who were a complete waste of time and money - or worse (the
ones who screw things up so badly someone else has to spend their time
fixing it all). I still do software development now, as well as all the
other things, because I enjoy it and (feel that I) have a talent for it
so I know how easy it is to be distracted, and have a fair idea of how
to avoid it. Being able to make yourself unavailable at times is pretty
much essential (but hard if you're in an office environment), but
imposing a good regime of short feedback cycles and transparency on
yourself is key. It's just better for everyone involved.
So yes, to finally answer your question, you're absolutely right - the
"regime" I describe could be used for in house developers just as well
as remote ones.
I need to point out that I would feel much better if the developers
themselves suggested a routine that aims to encourage transparency,
accountability and cooperation, as has been the case with a lot of the
developers I've worked with. Going along with the developers' way of
doing it, providing it gives you a similar level of progress monitoring,
is much preferred, as it is unlikely to meet any resistance, and they're
likely to have more experience using the system than any manager they'll
ever meet.
I would only impose ("suggest" is maybe better) a system on developers
who don't already have a system or have proved incapable of delivering
already.
Ronny.
Artan Sinani wrote:
> Hey Ronny,
>
> I understand all the points you make, but I don't understand what's
> the difference between managing a developer working remotely to a dev
> working in the office. The developers working in the office can also
> deliver little and waste time on other activities. In other words, the
> checking ways you describe, can apply to a dev in the office as well
> as to the remote one.
>
> I have been working remotely for almost one year now with the same
> responsibility to get things done as when I was working in the office.
> I find it hard to believe that a developer would reduce his/her
> productivity when working remotely. In my case I've found the opposite
> to be the case, as the interruptions are much less working remotely.
>
> Regards,
> Artan
>
> On 29 June 2012 05:22, Ronny Ager-Wick <ronny at ager-wick.com
> <mailto: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 <mailto:Chat at lists.lrug.org>
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org <mailto: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20120630/2522d9e5/attachment-0003.html>
More information about the Chat
mailing list