This morning, there were two talks, one by Paul Bauman and one by Tom Hawker, both presenting the types of tools people with large and complex VisualWorks + Gemstone applications have built and the experiences they've had. What impressed me was how truly large these systems are. And how small teams build them.

One point that stuck out to me from Tom Hawker's talk was the statement "ENVY got it right and Store didn't." To give that statement some context, Tom had been talking about prerequisite specification betwixt different code modules (whether you call them apps, subapps, packages, bundles, buckages, whatever). If I understood correctly, they were dissapointed when they converted from ENVY that no one specified these correctly.

In the context of maintaining code module integrity, I would add a qualified agreement. ENVY constantly nagged you, telling you what you needed to change to keep your prerequisites correct. In fact, ENVY went so far as to never let you make a change that would render the prereq tree invalid. You had to make the prereq change before you could make the change. Which sometimes created circular problems (anyone who tried to move ValueModel out of the UI Applications experienced this). This is where I think ENVY went to far and got it wrong. It never allowed module integrity to even be temporarily invalid. Store went the other direction. Threw the baby out with the bath water so to speak. A sort of "since it's nice to put module prereqs in an invariant state temporarily for some changes, let's do very little (almost nothing) to ever help maintain it."