There are essentially two approaches (both of which are useful and
educational) to the problem of building smaller modular images.

1. Start with the Image and Toss - The most popular has been to use a
tool such as Stripper of Packager as we called it to remove classes,
methods, instvars, globals and instances from the image. Packager also
allowed renaming of symbols to smallints as does Pocket SmallTalk I
believe. This approach avoids some of the initialization problem because
it always starts from an initialized image. The problem is that it
requires a lot of image and package knowledge expertise to perform the
work and often developers unintentionally make it challenging to
untangle an image so that it can be shrunk. 

2. Start with an empty Image and Add - the approach hear is to build up
a set of modular images from a set of carefully selected classes. The
problem of course with this approach is that it means that all
interdependencies need to be fixed in the existing classes. Often people
give up and decide to write their own new class libs as in  Pocket
SmallTalk. The risk here is that once you decide to build an image you
often own it for a lot longer than you intended. <grin> 

3. A compromise approach is to start with an image containing the
initialized classes
even if it is a cycle the they add in the classes carefully to build up
the image. This
finesses the hard problem of getting all classes to initialize
themselves properly
in some correct order. It also allows one to use the familiar classes
even if the lack the modularity and independence that one might ideally
like.

It would be really useful to have an Image Analysis and Planning Tool
which allowed one to understand the interdependencies between
classes/methods and globals.  Ideally one would be able to plan a
reorganize of the image without actually doing it in place. Being able
to see the impact of many changes before making them would reduce the
image FUD which one faces when trying to decide if you really dare make
those sweeping changes that you think are either trivial or impossible.
Hopefully the work by Stephan et al may come to play in such a tool. Our
experience with running the Packager is that the more often people ran
it the more they learned about problems in their image and the more
concerned they became about writing more modular code. 

Regards,
Dave