Redesigning asynchronous suspend/resume

Posted Dec 17, 2009 23:56 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]

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.

boudewijn said:

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.)

cpeterso said:

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 N² 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.