Re: [tlug] Giving a program priority briefly

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

Darren Cook writes:

 > > Note that Darren and Curt are talking about entirely different levels
 > > or scales of work ...

 > Really, it sounded to me like we were saying the same thing.

You really do profiling in a 5-minute off-the-cuff optimization? :-)

 > The point of the philosophy of distinct
 > refactor/new-functionality/optimize stages, at the sub-hour level, is
 > that it is easy to go back to a working version at any point.

YMMV, but I consider that the job of my SCM.[1]  I can, and regularly
do, commit one-character changes.  More likely, if I change a
parameter in the declaration, I'd grep -R for the function, fix the
call in each instance, then commit.  (Perhaps interleaved with various
distractions, see below.)

 > More realistically (at least in my work if I don't discipline myself)

That's what I see as the key word: "discipline".  In your case,
dividing into refactor/new-functionality/optimize stages provides that
discipline.  Great!  Don't change!  Recommend to others to try it,
too.  It might work for them, too.

But it might not, or they might have a better way (for them).  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.
I suspect this wouldn't work for most people, but for me it has the
effect that the working branch stays focused on the intended work.
Little doc fixes are now "fire-and-forget"; I just push them en masse
into the mainline.  The lilfix branch needs to be explicitly reviewed,
of course, but the main thing is not to get the fixes pushed quickly.
Rather the point is they don't get dropped on the floor, and they
don't interfere with the intended work.  That works for me on a scale
up to about 30 minutes.  Beyond 30 minutes, I need an explicit plan of
work, or the only thing I ever do is add YAGNIs to the code. ;-)

For the >30 minute hunks, I divide things up differently: review,
plan, implement.  Review corresponds to specification, and might be a
code review or a mailing list review (bugs or RFEs).  Then I plan
(informally, usually) how to satisfy the need discovered, then write
the code.  I think this corresponds to a biological (maybe even
philosophical) constraint, more than the suggestions about
refactoring, functionality, optimization do.

But I wouldn't even insist on that.  Rather, the need is for
discipline, not for a specific discipline.  Watts Humphrey says much
the same thing in _A Discipline for Software Engineering_.  Of course
I didn't understand it when I read it, only after I started to put it
into practice. :-$(D)P(B

Footnotes: 
[1]  git.  mercurial should work, too.  Darcs is too slow, as are CVS
and Subversion.  I don't know about monotone, svk, arch, or prcs, but
I suspect they're all too slow, too.