Jerry Nixon @Work: Where are the Patterns?

Jerry Nixon on Windows

Wednesday, June 18, 2008

Where are the Patterns?

Software patterns are repeatable techniques. Once you (or someone else) solve a problem, thn reuse the solution as a "pattern" for similar problems.

As developers reuse patterns, they accept them as "proven" techniques to solve common problems. Some proven patterns are DAL, web services, and command/view.

When the developer community shares patterns, they can become a lexicon for discussing problems and thread of consistency between different projects.

What is most important about patterns is that they are solutions; they are not the telltale of good architecture. A project does not need any pattern unless there is first a problem.

It is unlikely a project would implement zero patterns, even the smallest project. Some patterns are so inherent to development that we do not realize or consider them patterns.

To look at a project and BEGIN with an expectation of certain patterns (typically contemporary patterns) is an inexperienced approach to evaluating robustness or architectural quality.

Still, many magazine-educated developers read/learn about new patterns and subsequently evaluate their own code and projects against the presence of those patterns. They criticize the absence of these patterns, or undermining confidence in the existing solution(s).

No one denies that introducing new patterns into old projects can be beneficial. Some patterns supersede old patterns with better techniques. Business value and project costs must drive substantive retrofits more than a desire for the latest thing.

Little should be for the sake of cool – though some things should be.

The solution architect must lay out the system design, and then select patterns to solve anticipated high-level problems. He outlines default patterns to solve lower-level problems that may (or may not) occur – this promotes consistency.

Each developer solves individual problems every day. They use their own patterns that compliment the high-level and project-consistent patterns already in place.

Software patterns emerge as problems emerge. No worthwhile architect starts with the pattern and looks for shoehorn problems.

The next time you see a project and catch yourself wondering where ABC and XYZ patterns are, reconsider if the problem those patterns solves are relevant in the solution's context. Sometimes "simple" is the best pattern an architect or developer can implement.