Documenting a pattern in the way things change

-----

In debates over which code snippets and designs are better, the topic of how well the code weathers future changes often comes up. I have noticed a difference in the perception of the likelyhood of given changes among different developers. 

In particular, many OO fans view some change patterns with frequency assignments that I find artificial, and this may account for some of my distaste for OO. I have attempted to document my observations at:

http://reocities.com/tablizer/change.htm

Even if you disagree with my minority viewpoint, I wonder if anybody else has had issue with or has tried to document "the way things change" in order to better understand how to make code better able to handle change.

Sometimes I think that there is no long-term pattern to change, and that designs which assume patterns may be barking up the wrong tree. Shorter-term patterns are often dictated by the current mangagement of a given company or the nature of the current market. A management change or a new market direction has a way of turning even basic assumptions that earlier seemed like "invariants" on their head.  

There are more benefits in going after the shorter-term kinds of changes rather than trying to predict market or management upheavals in my experience. I sometimes liken business application design to "modeling the head of those who sign your paycheck". Perhaps domains that involve more physics and geometry rather than business and political "rules" can make better assumptions about changes because God won't be changing the laws of physics anytime soon. If God ran the universe like some bosses do, some mornings you'd fall ''up'' and the sun would rise in the north. --top

''This sounds like it could be a quite useful focus for pattern development, but how do you implement this idea? What are the individual patterns?''

I currently tend to focus on specific applications or industries. There's no general catalog I know of yet. That's what wiki's are for.

------
See also: PerceptionOfChange, DoubleDispatchExample, VariationsTendTowardCartesianProduct, CodeChangeImpactAnalysis, OopAndChangeImpact, CostOfChangeCurve, DecisionMathAndYagni, SimulationOfTheFuture
----------
CategoryPattern, CategoryChange