Regarding method factoring- It's interesting to note the impression one
has of a system that they are trying to repair, vs. the impression they
have of the same system when they are merely browsing through it casually.

There have been several times when I've called someone over to my
screen to show them some munged up collection of gargantuam methods,
only to be stymied by the fact that most of the methods are actually
quite small.  The difference is that the methods I needed to understand
in order to do the repair were NOT the small ones, but the very infrequent
BIG ones.  In my experience, the bigger a method is, the more likely
it is to accumulate complaints.

I think Terry Raymond's guideline is good- generally, factor things
out a fair bit, but don't worry about getting too extreme with it.
I actually have adopted a fairly extreme factoring approach for a few
years, but could easily back off a notch or two with no ill effects.
There's nothing wrong with getting too extreme ( other than the fact
that current browsers don't support you well in the task of understanding
long chains of messages ) but it doesn't hurt to ask whether the
new "sub" methods you create would be reasonably likely to be used
by any reasonable clients.  Sometimes, even for really huge methods,
the answer is no- to this day, I have one in my old grid generation
code that bothers me every time I look at it because it is about
four pages long with deeply nested blocks.  But no reasonable client
would ever use any of the submethods I could pull out of it, and more
importantly it works.  So, let it be...  But if it hadn't been working
correctly, it would have been refactored in a heartbeat.

However, keep in mind that one of the potential clients for a new
submethod could be some poor sap trying to wade through your code
in order to either understand it or ( more likely ) to repair it.
If you have nicely decomposed your methods, this person's effort
can be greatly reduced, or perhaps even avoided altogether.  Having
been that sap many times, I strongly encourage factoring for the
purposes of clarity and future malleability.

Happy Squeaking!

les