Collaboration is another aspect of working life subject to diminishing returns. As bad as a full day of meetings/calls/chats can be, recurring isolation also creates a sense of boredom and job apathy. Most jobs don't understand this and tend to take the side of over-collaborating.
I've got a more detailed comment on that page, but, in a nutshell, I don't think one can reasonably extrapolate these results to a business setting.
I'll go a step further here and say that I see this Science Daily article as a great example of questionable science journalism. Critical details left unmentioned, wild extrapolations, all that fun stuff.
I've soured on these sorts of behavioral study generally. They're so rife with statistical problems and publication bias that I think they pretty much amount to throwing darts at the truth, and as a result, whatever opinion you happen to hold about the right way to do $X, you can find a "study" to back you up. For or against pair programming? For or against open offices? For or against Agile? Oh boy, the literature has a study for you! (Or, if you're into nutrition, you can find studies for and against keto! Or for and against eggs! :Eyeroll:)
This kind of nonsense is what I like to call anti-knowledge. It tangles our decision making and it'd be better if it didn't exist at all.
While this experiment is too narrow to extrapolate to a business setting, I find it useful to have time to myself to think independently about whatever are the issues of the day. This is particularly difficult to achieve in an environment of constant verbal contact.
Of course, this is just a 1st. person anecdotal claim, so it certainly does not extrapolate anywhere.
I think this is especially true for SW engineering. You can't just constantly discuss things but you also need uninterrupted time to try out things and see how they work out. Then you can discuss the results again.
There was a third group where all members acted independently with no communication. The difference in likelihood of finding the optimal solution between that group and the one with intermittent communication was not found to be statistically significant in the paper, which is probably why they don't talk about it much. I think that knowing about it really does color the paper's interpretation, though.
It makes the cynic in me want to say that the real take-away here is that greedy search is more likely to get caught in a local optimum in a problem where the search space is not convex.
It's also worth pointing out that, to achieve P<0.05 on their main result, they had to run a LASSO regression with cross-validation. IMO, that counts as P-hacking.
The biggest problem for our team has been getting people to discuss more.
On befriending everyone and getting drunk one day, i asked them why don't you talk more at work?
They said, it's due to bad previous experience where they opened up and got attacked. Now, they only plan to speak when absolutely necessary otherwise, just solve the tickets assigned to me and i go home.
Some people, even in tech, are so afraid of being alone (often subconsciously) that they lean heavily toward group collaboration as a sort of security blanket. Outside-point-of-reference studies like this are really useful as aids in getting them to loosen up and let the people they e.g. supervise have some quiet time.
We kind of have the opposite problem on my team... all the devs tend to work mostly alone (98+% of the time). Most of the dev communication is with the product owner and the product engineers (non-devs).
We talk about doing pair programming or something in the next release, then we all go back to our respective stacks of work and don’t feel like we have the time to collaborate on anything, unless it’s a question for someone who knows a part of the codebase better.
If the results in this study generalize, neither constant collaboration nor constant isolation are good. You want people to be able to crib ideas from you in a professional setting. You also want them to have enough time to think up their own ideas.
I know you didn't ask for advice, but perhaps code-review and design-review is actually all your team needs? i.e. instead of the constant collaboration of pair programming, you work on slightly lighter weight interaction by having pairs of people work on closely related projects code-reviewing each other and having times where they bounce ideas off each other, but who ultimately work alone till they produce something the other can see. A half-day boundary of interaction (non-formalized of course) may be sufficient to allow for the degree of collaboration to be fruitful.
> lean heavily toward group collaboration as a sort of security blanket
This happens and fosters groupthink and prevents critical thinking and creativity.
When a whole team (or company) comes up with a poorly designed product this is often the reason.
You can fight this by talking about the problem, encouraging constructive criticism, engaging with communities and other social groups, gathering anonymous feedback from other teams.
One hypothesis could be that communication is the biggest barrier, in which case constant contact could be a solution. It doesn't hurt to test your hypothesises or consider alternatives.
