Its more fun when you get readers and besides, some of the feedback I've been getting here and elsewhere has made me either rethink and sometimes refine my positions.

On the Open-Closed Principle. In the whole, I don't think its an awful idea exactly. The idea being is you don't have to re-test what you didn't change. The flip side of this is that you *do* have to test anything you do change or anything that's new.

The assumption that is often made with these principles is that the original design is sound and a good fit for the problem domain. What about systems that need to evolve in environments where the current design doesn't fit the (recently changed) requirements very well?

In my rather advanced paranoia, I find myself factoring at a rather fine grained level to leave myself options in places where I'm not sure I'll need them. I consider this to be the essence of the architect's role - the preservation of options. After several years, my instincts have gotten pretty good, but I still get surprised every now and then.

Plus - how often have you had a system dumped into your lap that isn't in too good a shape and you still need to rev it to do some new kind of thing?

So I guess to sum up - the literature all assumes blank slate design or extensions of systems where the initial assumptions still hold. Thats all well and good - the real world isn't that neat. Our tools should be forgiving and help us recover from bad designs or sweeping changes in requirements. That would be the test of a good vs bad system for development of enterprise systems.