The Principle of Stability vs. the Principle of Release Early and Often

Over at Hamish's MishMash...

Patrick raises the flag for Smalltalk, and notest that it took ten years to get to the current version, Smalltalk-80. Which is now over 20 years old an substantially unchanged. There's an interesting question in there about how much of that stability is from it being "just right", and how much from the fact that once it's out there, it's harder to change. The balance is well over in favour of the former in Smalltalk's case. So "release early, release often" isn't necessarily the right way to go with language development?

Robert Martin developed the idea of "stability" in OO designs many years ago. The subsequent years brought battles in comp.object around whether this idea of "stability" is good or bad. In fact it is neither, just an observation that if many things depend on X then X is unlikely to change in ways that affects it's dependents. X may be "good" or "bad" by some other measures.

The same ideas can be applied to other kinds of design, e.g. language design as well as entire frameworks, such as the topic of the original messages, dotnet f/w. In my argument I am just assuming the Smalltalk system is "good" then I am attempting to explain how low stability for 10 years allowed it to become "good" before it became "stable". This is rare.

The original Smalltalk team did release early and often. But they were in the advantageous position to radically alter their design between revisions.

A commercial product like Hamish says, once it is out there is hard to change. So it depends on what "release early" means.

One product released to a small number of customers can change more easily than a suite of products (like the dotnet f/w) released to the entire world. If you are designing the ultimate in reusable platforms, this is a concern.