In that book, one of the concepts is that software development is not a perfectly partitionable task. Meaning a 10 month development job with 1 developer can't be broken into a 2 month development job with 5 developers.
This also falls a bit into brooks law that also says adding developers to a late project makes it even later.
What are your thoughts on this? Do you think software development is partitionable? Or do you think that concept was just a product of it's time (since it was written in the 70's) and we have come a long way to improve that aspect of software development?
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.
Did you read the whole mythical man month book?
Yes, actually, but it's been about seven years since. Why do you ask?
In that book, one of the concepts is that software development is not a perfectly partitionable task. Meaning a 10 month development job with 1 developer can't be broken into a 2 month development job with 5 developers.
This also falls a bit into brooks law that also says adding developers to a late project makes it even later.
What are your thoughts on this? Do you think software development is partitionable? Or do you think that concept was just a product of it's time (since it was written in the 70's) and we have come a long way to improve that aspect of software development?
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. ;)