Design Patterns

I stopped programming professionally on February 3rd, 1992, when I joined Microsoft as a Technology Evangelist. After that, any time I needed sample code showing how to use some new Microsoft technology, it was more effective for me to have a consultant code it up than to code it up myself. That way, I'd have the code, and a consultant that was up-to-speed on the new technology, too. I could then aim that consultant at companies who I knew were struggling to implement the technology themselves. Very efficient.

Unfortunately, this put me increasingly out of touch with rapidly-evolving programming practices.

A good example is the notion of "design patterns," which were first described (to my knowledge) as such in late 1994, nearly three years after I'd stopped programming. This is a double whammy, for two reasons.

• First, I don't understand "design patterns." It's another learning curve I have to climb. It's clearly possible to climb it, and I will make it to the top eventually, but it's just one more damn thing between me and my objective.
• Secondly, and more importantly, in the 15 years since "design patterns" were first described, they have become so deeply absorbed by the professional programming community that knowledge of these patterns is simply assumed. This is a huge pain in my ass.

For example, I eventually figured out that, to meet my need for "growing arrows," I would need to implement a custom Tween effect associated with a custom Arrow component. So I read Adobe's online article About Tween Effects, which drove me nuts. It seemed to be using three classes (Tween, TweenEffect, and TweenInstance) to do something that I thought could just as well be done by a single class. Since I'm trying to *understand* what I'm doing, rather than just programming by numbers, this apparently-neededless complexity was a real barrier to my progress. Adobe's documentation said nothing about why this complexity was present.

Then I noticed the word "factory," just once, in the About Tween Effects documentation:

• "mx.effects.TweenEffect: The base factory class for all tween effects."

I vaguely remembered once knowing the meaning of the phrase "class factory," which gave me just enough information to connect the dots from the documentation to the design pattern. So, I drive over to my local Barnes & Noble and bought the original Design Patterns book, plus another written specifically for Actionscript 3. These are ladders of knowledge, helping me scale yet another learning cliff.

I recognize that my situation -- of returning to programming after a 17-year hiatus -- is not common, and that Adobe can not reasonably be expected to write its documentation to accomodate such an uncommon reader. However, it does not seem unreasonable to suggest that, when a given feature of Flex relies on a specific design pattern, the feature's documentation should say so, and perhaps even refer to an online description of that pattern.

I do enjoy learning new things, but I *am* first and foremost trying to get a product out the door. It seems like I'm having to do a depth-first search among the roots of every darn language, tool, and framework, platform, and paradigm I encounter along the way -- and I have no idea how many more of these diversions I'm going to encounter. The number seems to be unbounded. That makes it very hard to plan ahead. This concerns me.