Re: [tlug] Giving a program priority briefly

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:

 > > The question is, have you scaled it in a project with complex
 > > dependencies among more than 5 programmers' areas of responsibilities?
 > 
 > Yes. Because every area is every programmer's area of responsibility.

Translated from the "American cowboy" dialect, that's "no, we don't
take on projects that the least productive programmer on the team
couldn't handle alone."  Doesn't sound so Xtreme when put that way,
does it? ;-)

 > "No code ownership" is surprisingly important.

Yeah, but that's in Brooks [1975] already.[1]  Responsibility !=
ownership.  Cf. where he says that one of the best decisions in OS/360
(!! that was 5 decades ago!) was to give each programmer a copy of the
*whole* engineering workbook.  Remember, we're talking about a *huge*
project; I bet you'd puke if you were asked to take programmers in the
low decile from that project, Brooks at the top notwithstanding.
Nevertheless, those slopehead bottom-decile keypunchers got the whole
thing, too.

He also points out that one of the big mistakes of the project was
granting ownership of "the code" in small units; when RAM budgets etc
started to bind, people started to look for what they could heave over
the partition into the next guy's cubicle.  He doesn't report actual
experience, but he points out the importance of getting each engineer
to "take ownership" of *all* of the code, even though he gets
responsibility (and authority) for only a single module.

The great managers have known this since before any of us were born.
It's a shame that each generation has to reinvent it and give it a
way cool moniker to get even 1% of the hackers and managers to pay
attention. :-(

 > XP is no substitute for communication, or at least asking why.

Then XP is not suited to handling complexity.  I'm not running down
communication; communication is the name of game in complex systems.
But any process intended to handle complexity must drastically reduce
the amount of communication per KLOC.

Incidentally, although my drink of choice is beer, not Kool-Aid, I
believe you have mischaracterized XP in this respect.  Getting things
right often involves paradoxical propositions.  For example, I'll bet
that if done properly, pair programming dramatically *reduces* the
amount of communication per KLOC of delivered product.

There are three effects that I have in mind.  (1) Pair programming is
said to be extremely (pun intended, but this is the precise word)
productive.  Thus KLOC output per man-hour goes way up, but there's a
pretty low upper bound on communication per hour.  (2) Because of the
pair experience, that pair of programmers can be extremely economical
about *future* communication, in subsystem integration, in testing, in
customer service, in maintenance.  (3) After pair programming you have
*two* experts ("fail-over" ;-), so that third parties experience much
lower costs of delay, which are (in this context) properly allocated
as communication costs.  And there may be other effects, too.

Nonetheless, I don't think it scales, unless you effectively have a
project that splits into small independent projects in the same way
that SourceForge does.

 > > However, there are a lot of tasks that it's simply not suited to
 > > in my opinion (eg, maintaining an Emacs or a kernel)....
 > 
 > Well, hmmm, tell that to a project which for the purposes of this
 > post, I'll just call "L". They use a lot less process than this.

*chortle*  Sorry, you just aren't getting me.  There's nothing that
says that to *have* a process you have to have huge files of memos or
even a written process manual.  In fact, anybody who's ever written
anything interesting (to me, at least) about process starts from the
proposition that *you*, too, *do* have a process.  Having agreed on
that, they immediately start to diverge over to what degree process
should be formal, etc.  But nobody sensible denies that process exists
in all organizations.

Now, if the Linux team ever decides to stick a fork in it, and move on
to something more interesting, yes, *then* they'll need to write it
down.  But until then, a policy manual is a YAGNI.

 > > It hasn't happened yet. Just because the lkml doesn't look like a
 > > SEI-certified CMM Level 5 shop doesn't mean that Linux doesn't
 > > have a superb group of project managers, top-notch engineers that
 > > anybody would be happy to have....

 > a lot of managers [...] not only would not be happy to have that
 > group, but would entirely freak if you even proposed it to them.

Sure, as a group they'd be unmanageable for 'most any outsider, and
there are surely individuals that no sane manager would hire among
them.  But I didn't say that they'd take them as a group.  Rather, in
that group the individuals are the level that any manager would like
to have (including large Japanese shops like NEC, where a couple of
the kernel hackers I know work/did work).


Footnotes: 
[1]  Yeah, published in 1975, but get the twentieth anniversary
edition from 1996.