Closure

[Ben Hyde <bh...@gensym.com>]

Jim Jagielski wrote:
> Is that a +1, -1 or 0 :) :)
> 
> Ben Hyde wrote:
> > 
> > The first frost, the hard frost, the leaves composed, the snow fell, the
> ...
> > > Rodent of Unusual Size wrote:
> > > > 
> > > > Tested.. votes?  Possible for 1.3, Brian?  MMN will need to be

I don't have the responsiblity of a vote, so that
would be a petition from a friend of the court.

It was a mistake though.  I haven't an opinion about
this patch.  It just reminded me of my primary
concern - that I may have to wait a very long time to
get a stable useful NT Apache for my customers.

I've spent more than a few hours over the last two
months pondering if there are devices that might
expidite the Apache release to closure.

It's important to me since I'm growing bored with all
this.  I'd like to: do my Beta, declare sucess, and
then dive into some other esoteric boondoggle.

In my private model of software projects I call this
"nailing the lid on the coffin."  I think there are
four levers you pull to make it happen.

(1) reduce inputs, (2) expidite, (3) manufacture buy
in, and (4) cancel stuff.

(1) tighten severely the permission to pile on 
  additional work.  

This is good because of two effects.  Labor,
precluded from working on fun/easy/amusing projects,
might then turn toward the remaining hard tedious
work.  The large risk of one of these "little" things
exploding in your face is eliminated.  The only risk
is that good people will wander off on forks that
can't be brought back at reasonable cost.  [[This is
a varient of the general rule that "piling on" kills
projects]]

(2) expidite process 

This is the only part of the process I believe
benifits from a daily meeting.  It can get a good
team sprit effect going that can substitute for the
pleasure of fresh interesting work.  This is when I
keep a public todo list - with names.  The risk of
this is that developers/cats don't like the close
control this implies.  [[This is a varient of "delay"
kills projects]]
 
(3) buy in

This is where a deadline is a huge help.  The "burn
the bridge behind the army" technique.  A public
promise, a customer demo, a trade show booth, etc.
Rhetoric can be helpful, it can backfire though.  By
the way, authority is useless at this point if you
boss people around at the point of closure they are
sure to quit immediately afterward.

(4) murder straglers

Tragic as it is you have to kill your young at this
point.  The risk is ovious, anger.  If your lucky you
let these projects fall off the wagon thru neglect
rather than with a act of violence.

---

I've enjoyed thinking about how every institution of
the for profit company has a mimic in the open
software community.  For example the shipping
department is mimic'd (sic) by the mirrors.

The open software community needs a conference to
provide deadlines.  As it is we are stuck with 
reteroric to achieve buy in.  I've not found the
mimic for the daily release meeting.

The way the namespace project went cancerous is a
textbook example of the risk of small projects
piling on late in a project.  That experiance ought
to frighten everybody into wanting closure now rather
than later.

I'm very happy that Brian's been doing some
more serious expiditing.

 - ben hyde