Does Remote Work Imply Strong Encapsulation?

We have a C++ project with three primary developers. The managing developer #1 is in L.A, developer #2 is in Berlin, and I am in Anchorage. The manager works with the boss and product designers and developer #2. I work with developer #1, and almost never interact with developer #2 in Berlin because of the language barrier and because our work rarely overlaps. I have next to zero interaction with anyone else like the boss or product designers.

The problem is that I am afraid to add new features because the trunk is so fragile. I am constantly stepping on the manager’s toes by committing test code right before a beta release, or writing code that doesn’t work with this or that platform nuance, and all of these problems happened because I was just plain out of the loop. We have no online forum or dog bowl to establish a sense of community, and what’s really bad is that I can’t write anything interesting that isn’t 100% in line with the manager’s current priority 1 bug for fear of getting a stressed out phone call from him. This includes cleaning up our mistakes from the start-up period, and writing example python scripts for our new scripting engine, of which no one understands how to use correctly. All three of our code styles are completely different, and there are strange looking blocks of code that have no comments explaining the obscure bugs they fix. I also haven’t been to LA to see them in 1.5 years.
So my question is, does working remotely imply that your role works like a black box, strongly encapsulating your function to avoid conflicts? Should I be given more interfaces to deal with, or should my manager work to provide this encapsulation? If you were to meet with your co-workers every, say 1 out of 6 months, how much would this affect your encapsulation? One month out of the year? As developers we can certainly work remotely, but at what point do you start to lose motivation as minion of many, and what can you do to promote interesting creative, and motivating work? I can’t add interesting features or do anything other than feel like a robot intern lapping at the task pellet feeder, and being a motivated programmer I find this mind-numbing, and I want to quit.
What are your experiences? Thoughts?
By | 2008-12-03T02:46:00+00:00 December 3rd, 2008|Uncategorized|3 Comments

3 Comments

  1. Patricio December 3, 2008 at 3:16 am - Reply

    Here are my lessons from the last five years:

    – Have regular (weekly) conference calls to keep everyone up to date.
    – Use an active web-based discussion forum for technical specs and discussions.
    – Schedule regular trips to meet and work with the team (every six months). This one is important.
    – Leave yourself a comment trail for your bugs by establishing strict guidelines for code style, bug tracking, and commenting non-obvious changes.
    – Establish solid and clear goals to keep your workers individually motivated. If you just feed them tasks all the time they will get bored fast.

  2. Bg Porter December 3, 2008 at 1:41 pm - Reply

    This sounds to me like bad implementation of distributed work; the kind of project that leads people to say that it can’t be done.

    I’ve been working in a completely distributed environment for 11 years now, and it works just fine (if not better) given the proper infrastructure. In my experience that includes:

    – constant, ongoing, automatically archived communications (we use a conference/messaging system called FirstClass, but you can use tools like Basecamp and Campfire for free or cheap).

    – common view of the project state and plan. We use a simple text-based task list that’s committed to SCM just like source, but there are many other ways to skin that cat. It’s just important that everyone agrees on what’s being worked on now, when it’s done, and what’s coming up next.

    – Common coding style. You can see ours (well, a mildly out of date copy) at http://www.artlogic.com/careers/styleguide.html It’s easy to get locked into pointless arguments about the One True Brace style, tabs vs spaces, etc., so refuse to. Decide once and it’s the law.

    In a properly run distributed team, working on a project shouldn’t be any worse than working with the same people in a traditional office.

  3. Calvin Spealman December 3, 2008 at 2:22 pm - Reply

    I am in a lead role of a distributed team with a lot of similar problems. I’ve tried getting a mailing list together, we chat in a private IRC channel, and we still have so many problems caused by just missed communication I can’t laugh about it any more. I’m doing my best, and I know they all are.

    Where the situation differs is that I can spend my time where I know its needed. I have a greenlight for refactoring and cleaning up the entire codebase. You would think that is a fantastic opportunity that would lead to all kinds of geek-happiness, but do you know what its like to try and refactor and redesign a large codebase out from underneath the feet of the other developers spread out in time zones from Honolulu to .. somewhere north-european? This is the kind of growing pains that remind me of the climactic end scenes of Akira.

Leave A Comment

4 + 5 =