After reading the discussions on method factoring and documentation, I
would like to suggest an experiment:  method hit counts.  A minor
enhancement to the Browser could count the number of times each method
in Base Squeak is read by the Squeak user.  Periodically, the counts
could be added to a central database for all Squeak users worldwide.

Methods with high hit counts would probably be
1.  the most used methods
2.  methods that are difficult to understand

Even for a well-written method, at least one read is usually necessary. 
But if a method is read over and over, it is probably poorly written or
inadequately documented.  Thus, the Squeak community could find which
methods need work.  Like many Squeakers, I feel that big picture
documentation is needed much more than API documentation.  Maybe this
experiment will identify groups of interacting classes and methods that
need better documentation.

In addition, assertions on issues like method factoring, for example 
Les Tyrrell's opinion from July 3,
-----------------------------------------------------------------------
>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.
-----------------------------------------------------------------------
could actually be tested.  Are bigger methods actually harder to
understand, requiring more time in the Browser?

Brian