It's difficult to partition software development work and always will be.
I don't think this is specific to the field; two mathematicians aren't going to produce a proof in half the time. Two novelists aren't going to write a book that's twice as good. Two artists, etc.
He goes into the underlying mechanics - it's due to communication costs, which scale geometrically as you add additional participants. It will always be a factor.
We've made some progress there - better abstraction and modularization help limit communication to defined interfaces, for example. Top dev orgs have learned to prefer tight teams of highly-skilled developers (versus large teams of low-skill developers).
And we'll continue to make progress - the trick is to find ways to reduce necessary communication, which is going to be some combo of reducing the number of people involved, reducing the info necessary per person, reducing the number of people any individual needs to communicate with, and maximizing the effectiveness of existing contributors (rather than adding more).
Imagine a network graph - now remove as many edges as possible, and minimize the weight of remaining edges (nodes are contributors, edges are communication). And don't accidentally cut essential communication. ;)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It's difficult to partition software development work and always will be.
I don't think this is specific to the field; two mathematicians aren't going to produce a proof in half the time. Two novelists aren't going to write a book that's twice as good. Two artists, etc.
He goes into the underlying mechanics - it's due to communication costs, which scale geometrically as you add additional participants. It will always be a factor.
We've made some progress there - better abstraction and modularization help limit communication to defined interfaces, for example. Top dev orgs have learned to prefer tight teams of highly-skilled developers (versus large teams of low-skill developers).
And we'll continue to make progress - the trick is to find ways to reduce necessary communication, which is going to be some combo of reducing the number of people involved, reducing the info necessary per person, reducing the number of people any individual needs to communicate with, and maximizing the effectiveness of existing contributors (rather than adding more).
Imagine a network graph - now remove as many edges as possible, and minimize the weight of remaining edges (nodes are contributors, edges are communication). And don't accidentally cut essential communication. ;)