Adapt to adapt

The more a program changes, the more tolerant of change it will become. It adapts to adapt. Refactoring achieves this. A program must have invarients - assumptions that it can make about the world and what is required of itself - and they aren't always values that can be set in a configuration file: see Invariants aren't always constants[?]. The assumptions which become ingrained into a program are structural, philosophical, and intellectuatal suppositions of what the program ought to do. These assumptions create Code momentum - a commitment that becomes harder and harder to uncommit to as the program accelerates headlong in a given direction. No other degenerate lapse of code sense is as uniquely horriable as Code momentum. By definition, huge amounts of search and alteration must be done manually - by hand - to undo the damage.

These rules cover key elements of refactoring and design related to Code momentum.

Adapt to adapt checklist:

• Objects and relational database systems - datastructures must match reality. Understand the relationships in the data and the code will follow.
• Abstract root classes - don't write implementations without first creating a separate interface describing all future implementations, of which the first implemenation is only one possibility. Talk about classes in terms of their abstract type to avoid hardcoding the program to one perticular implementation of a given fascility.
• Whole object[?] - the more objects exist in the system, the more chances you have to return objects to satisfy queries and standardize object types as input to methods.

• Law of Demeter - don't ask strangers in far away lands for help when you can ask cohorts and collaborates. Make requests that get you one step closer to the solutation, rather than try to nail it dead on. This limits interdependency between distant parts of the system: local changes only affect near by code.
• Facade pattern - create a demilitarized zone between developers to allow each developer flexiability in changing their interface, atleast until things stableize. This creates some turf that no one owns but anyone can dump code into in attempt to meet the interface requirements without making a mess of their own area. See also ModelViewController.
• Currying concept, Application generator - even the stickyist Cut and paste programming messes have solutions. These two concepts support the idea of OnceAndOnlyOnce.
• CPAN - Built the parts that can be tested first - that is, the parts that don't depend on non-existent code. Looking at this liberally, it could mean to create the nuts and bolts, or it could mean to create an articulated skeleton. Considering CPAN's offers when designing the project is Bottom-up design[?] at its best.

The article is originally from Perl Design Patterns Book

• Design pattern
• Planning is NP complete[?]
• Bottom-up design[?]
• Cross-sectional refactoring[?]
• Currying concept
• Application generator
• Once and only once[?]