Online asynchronous collaboration tools?

[jducoeur]

Howdy, all -- looking for thoughts, especially from the engineers in the crowd but not necessarily limited to them.

I've just found myself as one of the leaders of a big new software project -- big enough that we're going to be needing to spread the work across several teams, in various places around the world. That includes India, so figure ~12 timezones away from me. Collaboration is going to be a serious challenge, and one that we need to take seriously if we're going to succeed.

I'm sure that some of my friends have dealt with similar problems, so I'm looking for any and all thoughts. Tools, techniques, beartraps that you've run into -- this is an open-ended conversation, just keep it civil and accept that the team is what it is. I probably don't have the power to force this to all be on-shored, so the question is, how do we make the best of it?

We can probably slice-and-dice it so that different teams are working in different repos with distinct areas of responsibility, at least. The real question is how to manage questions and conversations about everything from coding style to architecture to requirements when we can't easily all get into a meeting together. It's not a rare problem, and I suspect there are best practices I don't know about yet.

Thoughts? Ideas?

Comments

[hudebnik]

Not an expert at this. I've been working at Google NYC for six years, and sometimes needed to collaborate with people in California, Switzerland, or Bangladesh, but haven't been involved in organizing any of the process or its enabling infrastructure; I just take them as they've been developed at Google over the past twenty-mumble years. Which probably means some of your questions aren't even questions for me; they're part of the air I breathe so I'm not aware of them.

As you probably know, Google has a monolithic, versioned code base (with a few things that are so secret I can't see them). To work on something, I create in my own cloud directory a modify-on-write copy of the whole code base (which takes seconds, since most of it is pointers to read-only snapshots), make my changes, test and debug and pass automated style-guide enforcers, create a "change list" and send it for code review to one or more other people, and once it's got all the necessary approvals (including non-automated style guide conformance and automated testing that I haven't broken anybody else's code), check it in (possibly re-syncing and re-testing first). If after checkin it turns out I have broken something, I or anybody else can rollback the checkin; that's a change list of its own that goes through the same process only faster.

Communication is through comment threads in an in-house bug tracker, comment threads on change lists, comment threads on shared docs, text chats and chatrooms, e-mail, post-mortems (a shared doc with a sharply prescribed form), OMG (a bug tracker modified for emergency outages), and occasional video chats, each of which can easily contain hot-link cross-references to most of the others (since all of this is within a browser). Oh, and until a year ago, F2F conversation where people were breathing the same air :-) Every bug has one owner at a time, plus a CC list; every change list has one or more people in its "attention set" at a time, plus a CC list. Shared docs and comments on them can assign action items to particular people.

I suspect you're familiar with all of the above, if not Google's in-house versions of them, but if there's anything non-obvious that I don't even know is non-obvious, having not worked at another software shop since 1984, ask me.

As metahacker points out, you obviously want to minimize the amount of stuff that needs to be handed off across time zones -- ideally, emergency outages and nothing else. It will save time if somebody autocratically decrees coding style standards, with a committee that can review them, gather public input, and again autocratically decree changes to them.

[jducoeur]

Some stuff that is already SOP, and some is very different from our micro-service, bazillion-repo world, but it's interesting to see the Google perspective -- thanks!