Planning game confusion over SLACK

[Jeff Grigg]

It seems to me that this whole thread has gone off the
rails. I'll try to recap what I think everyone agrees
on [...]. Everyone agrees that we should create as much
value as possible. [...]
Part of the value of slack is the "shock absorber" [...].
Part of it is stress relief--it's not good for anyone to
go on over-drive all day every day. Part of it is [...]
we don't always know what will [...] take the most/least
effort. [...] Part of it is acknowledging that we as
programmers have programmer tasks [...]. A good example
of a slack story is tool-smithing, automating some aspect
of development. [...]

The way I look at it, good healthy "slack" is most obvious when it's
missing: Being in a blind panic to just barely make it in time,
every time, all the time, is bad. Not only will it burn you out,
but it give you a classic "we don't have time to sharpen the axe"
problem. Sometimes, to deliver the most value possible per week
(instead of judging each individual sequential minute as a separate
sprint ;-) you need to sit back, get a little creative, and
realize, "Hey; there's an easier way to do this!" You can't get
creative when running like mad all the time.

Also, sometimes a little tuning, and possible tool smithing, is
needed.

I was watching a car race yesterday. Sometimes the drivers made pit
stops just to adjust the air pressure and top off the fuel. Doing
so improved their speed *during* the full-on race. You can't do the
Indy-500 without pit stops: You'll run out of gas, or the tires
will fall off. ;->