Working in Groups: Compromises or Contributions?

Some time ago, on a social media platform, during a discussion about technology, a pundit posted a piece arguing that teamwork was a horrible idea.  

The Compromise Theory:

His thesis is that an individual can have a great idea. When other people get involved, they have differing ideas. To settle the differences, the group has to make compromises. 

Every compromise is a degradation of the original idea's purity. By definition, he said, every compromise is a second-best choice. 

Eventually, the idea is so diluted and compromised that it is hardly worth implementing.

The Contribution Theory:

Cross-functional, diverse teams are well-documented and understood. They make better decisions, make rapid progress, and approach a problem from more angles. 

The thesis here is that "two heads are better than one" for problem-solving, and that the work of an individual (rather than being perfect and pure) is likely to have more flaws and a narrower vision than the work of several. 

There are plenty of examples of this in the world, including visual sensors that only recognise white skin, accessibility issues in which colour is used to denote information, and "tone deaf" uses of icons that confuse or anger people in different cultures.

Extra Context:

In practice, I've found that solo work feels more productive because one can push forward with extreme focus (AKA "tunnel vision") and complete their vision for how a feature or system "should" work.

If you want lines of code per day or the number of closed tickets, it's hard to compete with the solo developer who is in their best-known stack and possibly even aided by LLMs.

On the other hand, the solo programmer is unlikely to notice their own assumptions, tone-deaf choices, ignored nonfunctional requirements, and signature errors.  They may have a misunderstanding of the user, the problem, or the technology. If so, this is noticed well after the author feels they've completed or perfected the work. 

A request for changes feels like an insult and a personal attack on someone highly invested in the purity of their concept and its implementation. There is no certainty that solo programmers will react defensively, but it has been observed many times in many places.

Time spent pursuing the wrong idea is wasted. 

Teams help vet implementation and design ideas, rather than wasting time implementing them.

Individuals may base decisions about the code's design purely on what requires the least effort (or is more aesthetically pleasing) for them. In a group, ill-considered designs tend to be shot down quickly and better design alternatives suggested instead.

Which Is It?

Well, sometimes it can be either. 

It depends on the true purity of the original concept and the quality of the team's input. 

I think a team is rarely composed of one brilliant person and a number of dullards with nothing to offer. If that is the case, then certainly solo work is the only reasonable choice. The dullards should not challenge the one brilliant and competent member of the team.

Otherwise, perhaps we should consider operating in the Contribution theory rather than the Compromise theory...

... even if one of the developers feels otherwise.