Re: [tlug] Giving a program priority briefly

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

Curt Sampson writes:

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

But that's a bug for my situation; the checkout "I was working on
before" is not going to get into the product quickly enough.  You
simply can't avoid the integration headaches unless you can make the
customer swallow beta (better yet, pre-alpha :-) releases, or are
willing to withhold easy fixes until the next feature release.  OTOH,
if you mean to merge it *both ways*, then you're going to get a merge
conflict when you merge the current task into the mainline.

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

Nah, refactored stuff does *not* go into either lilfix or lildoc.  I
have to cooperate with people who lack the ability to read my mind.
That means that what gets into the lilstuff branches must be
"obviously correct" *and* preferably not conflict with others' work.

If it really makes sense to refactor, that's a new branch.

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

Well, obviously you're going to say that. :-)

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

In other words, there *is* an "appropriate place" responsible for
that, and you've just left it fuzzy and undocumented.  More of that
"undefined process" stuff, you see.

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

I have to disagree.  Communication is measured as data transmission
rate, not entropy.  Communication *is* cost.  What you're saying, I
think, is that the amount of information shared is increasing, both in
the sense of the rate of flow per unit time and in terms of the stock
at the end of the current task.  If you want to grab the word
"communication" for that, OK, but we'll need another word to talk
about the transmission process that directly generates the cost.
N.B. "Transmission" doesn't cut it because of the strong one-way,
mechanical connotation; "communication" is multilateral and interactive.

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

Well, culture does it best if there's continuity of task domain.  This
is why professors can get away with lack of process to the extent that
"absent-minded professor" is correctly spelled only with a non-
breaking space.  I don't think that the people working at Amazon and
Google have very much continuity in the necessary sense.

 > In many situations,

Sure.  Use the right tools for the job.