[jib]

The tasks are not the hard part. Alignment is a lot easier when you’re all close. I went from a distributed team (4 offices spread between EU and US) to a team that’s all co-located. The speed and quality of alignment is miles different.

There’s stuff we outsource (easy to describe tasks), but the stuff that needs tight iteration loops is so much easier when you can just get up, walk a few meters, and talk about it.

[pnako]

The Linux kernel is developed remotely. I'm tiring of hearing cat food delivery startups pretend it won't work for them.

[JoshTriplett]

The Linux kernel is willing to sacrifice the time of individual developers on the altar of project efficiency. That works for the Linux kernel because there are a huge number of prospective developers, and on balance the project doesn't generally care if any specific developer wastes some time or duplicates some effort.

That, by itself, isn't an argument that remote work for a given company will work.

[pts_]

Yacking wastes times of a developer any time of the day. Having to explain the manual to people who cannot read, doubly so.

[fsloth]

Linux kernel is also famous for a ton of input coming in, of which not a small percentage is discarded. It's quite an expensive model. For any 'normal' software project you have single teams responsible for single features. Not tens of teams competing who gets to create the version which gets accepted.

I'm not saying it's not a good idea to have competing delivery teams. But it's quite expensive.

[notacoward]

The Linux kernel as a whole is developed by people who rarely see each other in person, but there are several caveats that make it hard to generalize from that.

* Individual parts of the Linux kernel are often developed by people who do work together in an office (e.g. I used to sit with a bunch at Red Hat).

* Top-level Linux folks do meet in person fairly regularly, especially at LF events.

* Collaboration via email etc. is the primary workflow for the kernel, so there's no in-office cabal that has to learn new habits (and likely will resist doing so).

I'm also tired of hearing how silly startups can't do remote, but I don't think I'd hold up the kernel as an example that they could/should emulate.

[xxpor]

A significant part of it isn't though. For example, engineers writing a device driver for a piece of hardware are most likely sitting with each other and near the HW guys.

[baddox]

What is your argument? Those sound like two very different types of product development that I would expect to work very differently in nearly every conceivable way.

[pnako]

My argument is: if a complex project like the Linux kernel, or MySQL, or CMake, or pretty much any large piece of open source software, can be written by remote teams, I don't see what's specific about typical corporate or start-up technology that would prevent that.

[rusticpenn]

The difference is that, the developers are unpaid for the Linux Kernel.

[mkl]

Not true at all. In 2017, only 7.7% of contributions were unpaid [1], and it's been dropping for many years: "from 14.6 percent of contributions in 2012 to just 11.8 percent" in 2015 [2]

[1] https://thenewstack.io/contributes-linux-kernel/

[2] https://www.cio.com/article/2909736/who-s-behind-linux-now-a...

[rusticpenn]

Maybe I should have been clearer. The payments to the contributors and the targets of their respective companies are not always identical. A team from redhat contributing to the kernel might not be remote and will have their own performance measurement stratergies.

[pts_]

Which makes wasting money on meetings over comms through text even more glaring.

[14]

I really think that in the future people will use something like holoportation[0] to work at home or remotely across the world. Because like you say sometimes it makes sense to be present with a person to accomplish a task. It is very hard if they are trying to describe something when it would only take half a moment to visually look yourself and understand the direction the person is coming from. Holoportation looks very neat I really hope I get to try it one day. [0]:https://www.youtube.com/watch?v=7d59O6cfaM0

[newqer]

When I'm retiring, +/- 30 years from now, I'm going to put on my Virtual Reality glasses and never leave the house again.

[runawaybottle]

Don’t underestimate humanity’s ability to adapt to staring at screens as the norm (on a societal level).

[eecc]

I’m sorry if I sound harsh. The problem is not a matter of better or worse “alignment”.

It’s just poor quality planning and execution.

Your team is just improvising, figuring out as you go, what is exactly that you need to build.

It’s not even Agile. Agile is about tight loop upfront planning, and avoiding last-minute distruttive changes and meetings...

[ascar]

> It’s not even Agile. Agile is about tight loop upfront planning, and avoiding last-minute distruttive changes and meetings...

That's an abomination definition of agile, probably influenced by scrum. In the agile manifesto it says nothing about "tight loop upfront planing", however it does explicitly say[1]:

> Individuals and interactions over processes and tools

> [...]

> Responding to change over following a plan

While that doesn't mean all planning is bad (it isn't and the manifesto acknowledges that), the planning is not the agile part, it's the leftover of the original traditional management, because it is necessary to a certain degree (e.g. for alignment but also for a lot of other business related tasks).

If you're running a pure kanban approach, you don't even plan in tight loops and I had much better experience with that (and a single team lead with a good strategic vision) than I had with Scrum. Scrum is just easier to handle for big (old) organizations and gives developers some protection from bad management.

[1] https://agilemanifesto.org/

[eecc]

> That's an abomination definition of agile, probably influenced by scrum. In the agile manifesto it says nothing about "tight loop upfront planing", however it does explicitly say[1]:

Sure it might be an abomination, but if we set the rhetoric aside for a minute we should consider the option that the context where Agile is applied isn't just RoR rockin' startups in the Bay. Lets call it dilution perhaps?

Besides, there's context. The Manifesto was drafted in a world still reeling in RUP and floor-wide teams marching towards quarterly releases.

That wasn't sustainable, but neither is "responding to change over following a plan" if that means moving targets every other day. That's a recipe for burn-out, and sprint commitments are sacred.

So yeah, context: respond to change means reassess every some sprint, not pivot 3 times a week.

/s (tongue in cheek people, life's too short for zealotry)

[solveit]

> It’s just poor quality planning and execution.

Potato potato. If you can get away with "poor quality planning" in person but not in remote, it doesn't matter what you call it.

[scarejunba]

You get 11 weeks until Demo Day. If you spend it learning how to plan better you've already lost.

[eecc]

Well, that's assuming you still don't already know how to plan or even put your thoughts on paper.

If that's the case, you shouldn't be in the business unless you're in a junior/apprentice position (which is fine, one has to start somewhere.)