Redesigning asynchronous suspend/resume
Posted Dec 17, 2009 19:43 UTC (Thu) by cpeterso (guest, #305)
there's the second system effect and the mob of
Brooks assumed that new developers would negatively impact existing developers' productivity. I don't think that applies when the pool of potential Linux developers working is (practically) infinite. There is little cost to Linus/Linux if dozens of autonomous developers are all writing their own Linux process schedulers.
Posted Dec 17, 2009 23:56 UTC (Thu) by jzbiciak (subscriber, #5246)
I'm going to reply to both of you in one spot. :-)
Unfortunately, I don't have my copy of Mythical Man-Month with me, so I can't quote him directly.) In more recent editions of MMM, he includes essays that look back on some of his original statements, and presents refinements, counter-arguments, and clarifications.
there's the second system effect
With respect to this and the "throw-one-away" comment, he pointed out that if you take both literally and out of context, this would seem like a recipe for disaster: You'd throw your first system away, and end up with your second system rife with feeping creaturitis. (Obviously paraphrased.)
He goes on to say that the two are talking about different things. The first one refers to multiple implementations of the same system. The second one refers to the second complete system as a discrete entity / project from the first. The Linux kernel is too large a project to be described in this manner, IMHO. It's more interesting to look at individual subsystems, and even then, only when the same group of designers implemented major revisions of that subsystem. (Recall, Brooks describe the "second system effect" in the context of a particular designer's second system.)
Perhaps Linux development breaks another of Brooks's laws: Adding manpower to a late software project makes it later.
As I noted above, I don't think you can apply that to the Linux kernel as a whole, because it's actually a collection of many, many smaller projects. The whole of Linux marches forward mostly-independently of any of its constituent pieces. Something doesn't stay merged if it breaks things.
For one thing, Linux defies the notion of "late," since "late" only makes sense relative to a schedule. "When it's ready" is not a schedule. That doesn't mean Brook's Law is invalid, it just needs a change in nomenclature. A more accurate restatement would be "Adding more developers to a project that is well on its way to completion will delay that project's completion, due to the overhead of bringing the new members up to speed, and the additional need for cross communication among developers." In particular, he notes that the number of potential communication paths among developers increases as the square of the number of developers.
In this more general form, I believe Brook's observation does still apply, at least to a major discrete feature development at the subsystem level. If you look at any such addition, rapid progress on its implementation does generally slow down when it's opened to a larger community, because of the additional communication overheads. The "last minute Linus effect" is just a particular manifestation of this property.
In later versions of MMM, Brooks' retrospective does point out that there are organizations that have shown much better productivity scaling than the N2 developer interactions suggest by segmenting the work effectively. In Linux kernel land, I think this directly translates to the notion of discrete subsystems that largely don't care about each other most of the time, thus enabling them to remain independent of each other and considered separately.
Posted Jan 6, 2010 21:42 UTC (Wed) by jchrist (guest, #14782)
Posted Jan 6, 2010 22:18 UTC (Wed) by mjg59 (subscriber, #23239)
Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds