[jude-]

One strategy I've found works for me is to keep a document explaining why you designed the system the way you did. What were the alternative possibilities? Why didn't you pursue them instead? Do so without referencing projects or implementation details, and derive your reasoning from first principles.

I revisit the document as I'm working on a project, so when I go to code a new feature, I make sure I can justify the need to create it with respect to the larger design of the system it lives in.

[EdwardCoffin]

This reminds me of a tip Guy Steele gave in his talk on the Language Design panel of the Dynamic Languages Wizards Series in 2001 [1]. He said: It's important to establish design principles early on, that is in effect to do meta-design, because as you evolve the design, or as the language grows later, you want to remain true to an initial vision. This has to do with keeping the description small, and if you can resort to a meta-principle to help you resolve a particular design decision, it keeps the language more consistent. (17:09-17:29) [2]

[1] http://www.youtube.com/watch?v=agw-wlHGi0E

[2] http://www.youtube.com/watch?v=agw-wlHGi0E#t=17m09s

[jude-]

I didn't know about those videos. Thanks for the links!