[linux-elitists] advocacy blurb

Mike Touloumtzis miket@bluemug.com
Mon Sep 11 15:42:33 PDT 2000

Warning: gratuitous, narcissistic punditry ahead.

Recently I've noticed an increase (maybe it's my imagination) in
the number of doomsayers/pundits who have taken to criticize the
Linux kernel developers for failing to adhere to "professional"
software engineering practices (thorough documentation, careful
release practices, listening carefully and respectfully to the sage
advice of J. Random Experienced-Engineer who generously offers up
his wisdom on LKML).  We've always had the "teenage hacker/weekend
project/no roadmap" kind of FUD, but this newer stuff seems to be
coming from a better class of lifeform than previously.

I'm far from thinking that Linux kernel development is perfect,
but that shouldn't be a barrier to advocacy :-).  In response to
this kind of argument, I suggest arching the eyebrows and trying
out the following.  Like all carefully planned advocacy, it tries
to attack the opponent's worldview.

J. Random Engineer: "Linux kernel developers don't understand
quality software engineering practices.  Why, they hardly comment
their code, and they don't write design documents."

You: "You just have to look at it in economic terms.  Conventional
software engineering best practices developed in an economy
characterized by:

	-- Scarcity of engineering resources
	-- High risk of personnel turnover
	-- Average distribution curve of engineering expertise
	-- Scarcity of expert advice

In light of this type of economy, are you sure that traditional
engineering practices are the best?  For example, if you assume
a glut of engineers seeking to get patches into the kernel, but
a scarcity of patch review time by the core kernel developers,
isn't it optimal to make it hard to submit patches?"


More information about the linux-elitists mailing list