Re: [tlug] Giving a program priority briefly

[Darren Cook <darren@example.com>]

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

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. If you
change just one thing between running the tests then if it breaks you
know the problem, or at least have a very big clue. If you change two
things, you have more work to do.

More realistically (at least in my work if I don't discipline myself) I
spend half an hour on: adding a new parameter, change the code that
calls it, fix some documentation as I go, rename a function, rename a
parameter name, move a function up or down a class hierarchy, reformat
some code so I can understand it better, then say, "OK, beautiful, lets
see what breaks". And when it does break, I'm potentially looking for a
needle in a haystack (*). It is often easier to just throw away my half
hours work and start again, in smaller steps, from the last good version.

Darren

*: Even something as trivial as renaming a parameter can cause very
subtle bugs if the parameter name was also the name of a variable in one
of the base classes. Tip of the day: use -Wshadow in g++.