On Aug 8, 2006, at 2:31 PM, Andreas Raab wrote:

> Dean_Swan at Mitel.COM wrote:
>> Regarding modularity, wasn't there an Idea that future work would  
>> be based on Craig's Spoon work?  That at least offers a repeatable  
>> process:
>>         1) Start with a "full" image version X.Y-Z, execute some  
>> method(s) designed to exercize the desired funcionality to imprint  
>> a new "minimal" image
>>         2) Save the minimal image and give it a name/version.
>> It seems that S-unit tests of some sort would provide the basis  
>> for the method to imprint the desired functionality.
>> Is there any reason why this isn't a good path to follow?
>
> As the *only* path? Or as part of an overall strategy? If the  
> first, I'd say that I'll answer that question once I've seen the  
> first system that has been built that way ;-) [*] As part of an  
> overall strategy it's perfectly fine - there are various  
> interesting ideas in Spoon which can be helpful in many different  
> contexts.

I'll echo this opinion. Spoon does nothing to make the system more  
modular. It does make it easier to unload parts of the monolith,  
which is useful. It may also help us figure out what where some  
dependencies are, which is also useful.

The only way to make the system more modular is to figure out where  
the dependencies are and rewrite key bits of code to remove them.  
Sometimes it means introducing new abstractions like ToolBuilder or  
Services to enable looser coupling. Sometimes it means tearing out  
and throwing away code that's too entangled to remove cleanly,  
something we haven't been willing to do so far.

There's no getting around the fact that it's hard, ugly, unglamorous  
work. Spoon is a good tool, but it's not "the answer."

Colin