My point is that that rapid prototyping stage is really important, has long lasting consequences, and so optimizing for it is a reasonable decision.

And that's just one reason to disfavor a remote-only environment.

Rapid prototyping happens only once per project and is likely less than 1% of the time spent so to me it does not make sense to optimise for it.

What other reasons do you see to disfavor a remote-only environment?

Rapid prototyping should happen every time you need to add or change an abstraction. With the way many (most?) software projects work, with new feature requests and requirements appearing along the way, this happens all the time. With new requirements, the old abstraction often doesn't fit 100% anymore. Applying a few band-aids to the abstraction is probably fine, but at some point you will need to reconsider the design, or you will end up with a design that does not match the problem it's solving, making the code difficult to follow and therefore error prone.

In my experience, this need arises very frequently in complex systems with evolving requirements.

Oh, don't get me wrong. I fully agree! What I was saying is that the initial rapid prototyping of a project is happening only once.

Our company offered us to sometimes reconvene physically and discuss such things but since our team are all family men, it hasn't happened yet. But it is a really good idea and we should reconsider actually doing it sometime.

That 1% (and is often more like 5 or 10) can have big implications, but you can just have an on-site, it's a lot cheaper than having an office year round. Plus you can do it somewhere fun and it's a great perk and team building exercise.

> that rapid prototyping stage is really important

This is an excellent argument for annual all-hands retreats for distributed companies.

So you're going to discuss all your designs in February? What if you need to make a major modification to a design, or like some priority changes or whatever.

The whole idea of agile is to design iteratively and reactively, but you're throwing that away.

I suppose if your process relies on that type of design happening regularly, remote work is not going to allow for that. But I don't think colocation is a requirement of iterative & reactive design.