Re: [tlug] Giving a program priority briefly

[Curt Sampson <cjs@example.com>]

On Tue, 12 Jun 2007, Stephen J. Turnbull wrote:

> For example, to deal with the kind of distractions you mention, I've
> added two commands to my SCM: commit-to-lildoc and commit-to-lilfix,
> where lildoc and lilfix are branches where I accumulate such random
> changes. ...but for me it has the effect that the working branch
> stays focused on the intended work.... The lilfix branch needs to be
> explicitly reviewed, of course, but the main thing is not to get the
> fixes pushed quickly.

I think you mean "to get the fixes pushed quickly," right?

I have a similar strategy, except without the later integration
headaches: I keep a couple of checkouts around, and when I need to pause
for a sec to fix something, I fix it in a clean checkout, test, commit,
and then merge that back into the checkout I was working on before.

This works particuarly well for me in that these sorts of changes are
often not terribly related to the "main" thing I'm working on at the
moment, but something that touches it and makes doing the main thing
easier.

You can think of it, perhaps, as sort of an "I should have refactored
the code base this way before starting in on this feature" moment.

On Sat, 16 Jun 2007, Stephen J. Turnbull wrote:

> Curt Sampson writes:
>
> > 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, but that would be a gross misinterpretation. While every programmer
is responsible for not breaking stuff, there's no rule that says you
can't go seek help when you need it. In fact the rule is that you
*should* go seek help from the appropriate place when you're unusure.

> Nevertheless, those slopehead bottom-decile keypunchers got the whole
> thing, too.

Of course. How are they going to grow, otherwise? The best thing about
allowing anybody to work on anything is that someone can go off and gain
some understanding of another part of the project, and everything he
does from then on will incorporate that understanding.

I'll refrain, at the moment, from pondering how this might work on very,
very large projects. (Yes, that's a cop-out. As Clint Eastwood said, "A
man's gotta know his limits.")

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

This was interesting enough to deserve quoting in full, especially after
this amount of time. But I think we have an argument about whether
this really is a decrease in communication. I would instead posit that
it's an increase in communication, but a decrease in communication
*costs*, and further posit that an increase in communication is at worst
harmless, even actively good, and it's really the cost of communication
you should be trying to optimize, not the amount.

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

Given that viewpoint, I'd say that XP teams then do have a large amount
of process, albeit very informal.

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

Right. Use just as much formality as you need to preserve the process
as best you can. Culture does it best, and you start adding more formal
things to compensate when you can't maintain the culture any more.

In many situations, I think it's probably cheaper to keep a couple of
developers working on the system and making improvements than it is to
try to write a manual for the system for later use.

cjs
--
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
Mobile sites and software consulting: http://www.starling-software.com