LWN: Comments on "Redesigning asynchronous suspend/resume"

Redesigning asynchronous suspend/resume

mjg59 — Wed, 06 Jan 2010 22:18:45 +0000

JWZ

Redesigning asynchronous suspend/resume

jchrist — Wed, 06 Jan 2010 21:42:20 +0000

I'm trying to track down the original "mob of attention-deficit teenagers"
source without any luck. Any pointers?

-Jon

Redesigning asynchronous suspend/resume

jzbiciak — Thu, 17 Dec 2009 23:56:35 +0000

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.

Redesigning asynchronous suspend/resume

cpeterso — Thu, 17 Dec 2009 19:43:15 +0000

there's the second system effect and the mob of attention-deficit teenagers.

Perhaps Linux development breaks another of Brooks's laws: Adding manpower to a late software project makes it later.

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.

Redesigning asynchronous suspend/resume

halla — Thu, 17 Dec 2009 18:09:48 +0000

On the on the other hand, there's the second system effect and the mob of
attention-deficit teenagers. Though in Krita we've rewritten the core at
least four times, and I'm definitely not a teenager anymore.

Redesigning asynchronous suspend/resume

jzbiciak — Thu, 17 Dec 2009 16:11:18 +0000

I'm reminded of Fredrick Brooks' statement:

Plan to thrown one away; you will, anyhow.

Of course, Brooks' aphorism is a bit over-compressed, and he's noted its limitations in later essays. I can't help but think, though, that these massive reworks are only successful because the thing being reworked already exists and already shows benefits despite its warts. That gives incentive to go back and fix the things that are clearly not right, but retain the value.

"Because it took a lot of time to write" is a horrible reason to keep a piece of code if you can see that there's clearly a better way to do something once you get to the end. And besides, this massive rework took, what, less than two weeks? (Rafael's pull request was dated Dec 5th, and today is 12 days later.) If you covered the original patches back in August, then comparing the 2 weeks relative to the previous 3+ months doesn't feel so bad.

Sometimes you don't know why something is bad until after you've implemented it. The rework that happens at the end benefits from hindsight.