There are times when it becomes important that we step back from our work to really understand when / where / how patterns are applied. However, where I think many of us fall short, is more importantly is when NOT to.

Like any great pattern that is meant to simplify and organize, they can abused and overused. Remember, a pattern is really nothing more than a general solution to a particular problem set that has been previously solved. So for many cases, this is a godsend, because it means less time can be spent on the implementation and more time can be spent on the UI, aesthetics, and over all product improvements.

So applying a little ‘truth serum’ to the task we’ve been given, here are a few questions you might want to mentally ask yourself before diving in to get your particular problem to fit. Afterall, what sense does it make to try to pound a square of Jello into a round hole.

  • Just how likely is it, this code will ever be used again in some other project? I know there’s always the over inflated projections of how good the code really is, but if it’s for something fairly specific, chances are it won’t be ‘black box‘ ready, and at best would be white box ready. Utilities, collections, and object managers typically make for a good case to go the extra mile, but specific UI elements, forms and screens usually do not.
  • Just how likely is it this code will be used by someone else? As the number of people working on the same team increases -and the important part that gets over looked- the same project, it becomes more likely that judicious use of patterns will help. What I mean by same project, is not a bunch of developers all working on different unconnected segments, but the same product as a whole. If what you’re working on isn’t interconnected with some one else’s code, this becomes a warning flag that it’s possible to over do it.
  • How many connections will it have? This typically applies at the class or module level, but can just as easily correlated to the over all project. The less highly connected something is, eg compartmentalized, the less likely that it will perform or see a significant cognitive gain with an applied pattern.
  • How long it expected to live? Particularly Flex and Flash, have such a short life cycle it becomes almost unmanageable to keep up with each new iteration and still some how stay connected to all that code you wrote and no no longer works. For very good monetary or reasons of usefulness / pride, we try to update things to their newest revisions, however we do need to be mindful that every thing that has a beginning has an end. A good example of this is older custom components that dealt with a displayList in either masking or elaborate MovieClip management before such a beast existed in the AS3 world. If the component still has a significant need or contribution, then it might make sense to rewrite it. As the cradle to grave cycle shortens, it makes a lot less sense to over zealously apply patterns where it just won’t live that long.

When you build a scorecard based upon your answers to questions like these, it may help to give a little perspective in where you might get the best code efficiency / usefulness vs. the time spent to set up the scaffolding nearly all patterns need.