Build Learn Abstract

This is paraphrased from a talk DougSchmidt gave to a joint meeting of the San Francisco and Silicon Valley Patterns groups. This is similar in spirit to the evolving-frameworks patterns [1] of DonRoberts and RalphJohnson.


Build a collection of related systems


Learn from the systems you've built. Learn which requirements are generic and common, and which requirements aren't. Learn which solutions worked well. Measure and test system performance. Study other systems for applicable solutions.


Refactor existing mechanisms into abstract mechanisms ready for subsequent leverage.

...and repeat.


I've been thinking of ways to refactor the ExtremeProgramming tenets of using only incremental refactoring to guide your design, while at the same time somehow drawing on a global knowledge of programming practice (know everything) (see TooDeepIntoTheBagOfTricks for a related discussion). It seems in the interest of encouraging incremental development, a novice programmer might be discouraged from directly studying the works of others . But why can't study of the works of others be done incrementally as well? BuildLearnAbstract is how it is done in the world of framework evolution. Maybe there is an equivalent for OO application developers not necessarily concerned with creating frameworks for third-party use: ExperimentStudyRefine? --ScottJohnston

View edit of November 6, 2002 or FindPage with title or text search