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

[juan_gandhi]

I recommend slack. I've been using it for about 9 years now. Replaces email. Configurable (you can add bots). And, what some people may find important - no BCC available.

[danabren]

I second this.

Off the top of my head

[metahacker]

Hmm. Sympathies.

With total schedule inversion to India, you're going to need realllly good hand-offs between teams; I've worked in that situation (plus an outlier in England) and basically round-trip takes 2 extra days. So the goal is to make people as autonomous as possible, which means as little merge-pain as possible up front. (And I don't just mean code merges, though that is a concern--I mean expectation-merges, thought-merges, etc.)

I like this idea though I haven't had a chance to implement it since reading this essay:
https://medium.com/morozko-method/use-unless-otherwise-ordered-uoo-to-empower-subordinate-initiative-da408c97d252

It does mean being clear-eyed about what you actually need from each other, and being annoyingly explicit about action item owners and such.

Tactical stuff:

Style guide: my suggestion is to be draconian with this. Right now my solution is "use Prettier, period". It's opinionated, but it also completely normalizes syntax-level arguments. Bonus: never fight with spacing/brackets again while writing or moving code.

For coordinating over code between developers, I suspect you already know a lot of the tools, but the review-and-merge tools built into e.g. GitLab keep getting better, including in-place comments and test results, connection with JIRA/wikis, etc., etc.

Ticketing systems (JIRA, GitHub issues) are the worst solution except all the other ones that have been tried. Again I suspect you're on this track already.

For unstructured DTDP (different time, different place) coordination, well, the tool you know best is best--wikis. The wiki software built into GitLab or GitHub is "good enough" for most uses.

The trick is that you (as a team) need to exert opinionated control over these tools; without a strong process, you're trying to push a rope. What're the steps to finish a code review? who gets to take those steps? What steps must be completed before beginning to implement a new feature? and so forth. The wiki can hold pages with all this stuff in it--no one will read it at first, but it's great reference.

Finally, expect to have a meeting at least once a month where people are drastically out of time zone, either you or them up at 4am or 11pm. Because there's always the et cetera the above simply can't handle...

Re: Off the top of my head

[jducoeur]

Useful pointers -- thanks!

Style guide: my suggestion is to be draconian with this. Right now my solution is "use Prettier, period". It's opinionated, but it also completely normalizes syntax-level arguments. Bonus: never fight with spacing/brackets again while writing or moving code.

That bit's a non-issue -- at this point we recommend formatters company-wide, and I enforce them rigorously. If you're using the tools properly it gets formatted in the IDE and checked during pre-commit. And it fails the build if for some reason that hasn't been done.

For coordinating over code between developers, I suspect you already know a lot of the tools, but the review-and-merge tools built into e.g. GitLab keep getting better, including in-place comments and test results, connection with JIRA/wikis, etc., etc.

Yeah, we do a lot of this. (Even before this, my team is scattered around the country, and we have a mandatory 2-review rule, so tooling's critical.) In practice, we probably need to give them their head as much as possible, just to keep from slowing them down too much. Coordinating about things like APIs and schemas is going to be the more critical bit, I suspect.

Anyway, excellent food for thought -- thanks again...

[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!

[cellio]

A thing I've seen bite many people between our US-based folks and our India folks is forgetting that questions cost a day (minimum). "Can you clarify such-and-such" (requirement, bug report, whatever) means you'll get your answer tomorrow at best, and then if it's incomplete or vague or otherwise inadequate and you need to ask for more, that's another day... and these are best cases. So: front-load information, be clear about requirements and requests, err on the side of saying more. Better "yeah I already know that" than "what do you mean I need to frob the whazzit? what does that mean?"

[jducoeur]

Yeah, I'm painfully conscious of that one. And the lag time is one of the main reasons why I'm cautious about just relying on Slack (which various folks have recommended), which is good at lightly-async conversation, but IME sort of so-so at heavily-async. (And not great at conversations requiring large blocks of information at a time.)