Development Patterns for Technology ™

People in technology use patterns for everything from coding strategies to development strategies to interface design. We follow patterns because patterns a pattern represents a safe plan to a result that generally someone else has done before and validated. But patterns can also lead us into a false sense of security by turning innovators into followers and turning our products into another version of what has been done before. I thought I would offer my own thoughts on the benefits and pitfalls for following development patterns for technology ™.

I was reading an interesting
TechCrunch post about public relations titled PR Secrets for Startups by Brian Solis. This caught my eye because, as many of you know, Open Mountain targets startups as our primary customer. What was interesting in this post was the comment on PR “patterns”. PR firms had, over time, become less about relations to the public and more about following a certain pattern of information dissemination.

Something we should share begets a press release to the Roladex and PR wire. Why do anything different?

His point was that PR had fallen into the above pattern of action and that Web 2.0 may have finally shocked the PR industry out of this rut. Truth is, pattern behavior is all around us, which in turn leads to automated decision making and that is bad news.

Take open source as an example. A few years back, Linux finally established that open source software works as good if not better than commercial software. Suddenly, CFO’s were slashing IT budgets and demanding that their teams go open source full throttle because it was free. Does anyone still think open source means free? No. Once the CFO’s got over this pattern, we settled into the process we have today for evaluating open source right along side commercial software.

As another example, during the height of the boom, many investors were pushing Java running on BEA servers on top of an Oracle database because that was a pattern they knew worked. Of course now we know that the pattern of JBoss with MySQL is equally viable and less expensive for startups.

Patterns at the end of the day are neither good nor bad. The best companies and thinkers see the pattern as another data point. Following established development patterns for technology ™ has some nice benefits, but in the end this is just another decision along with what language to use, when to launch, how to host your solutions, etc.

Here are five benefits to consider when selecting or following a pattern:

1. Communities form around patterns. People doing similar things are likely to share their experiences, and the resulting knowledge base is definitely beneficial to the community.
2. Patterns create stability through consistency. Solutions are more stable if the underpinnings are based on technologies and methodologies that are tried and proven.
3. Once you decide to use a pattern, the set of new decisions you need to make shrinks more rapidly than without a pattern. Teams can move faster by focusing on decisions outside the pattern.
4. It’s less risky to follow than lead when it comes to everything but your core competency. You want to be leading edge with your core competency and the soul of your business. Patterns allow you to use the experience of others to solve everything else.
5. Patterns are easier to communicate to non-experts. Once something becomes a pattern, it is often synthesized down to a key set of principals and benefits that are easy to share with the world.

But if you follow a pattern, here are some things to watch for:

• Be wary of patterns that are not driven by experts. Having an investor tell you to use Java is not the same thing as reading it on TheServerSide or hearing it from James Gosling.

• New patterns do not have the same benefits as established patterns. A great example of this is the scalability of Ruby on Rails, which is a hot issue right now. Some industry experts have expressed a concern over the scalability of the RoR pattern based on the experience of a few companies. I have no doubt the scalability issues will be solved as they were with Java and enterprise beans. Established patterns are less likely have these types of fundamental issues.

• Patterns can lower your decision making capability. At the end of the day, a pattern is a tool not a solution. People following patterns can forget that and start to make their decisions based on what others have already done. If you follow that trend for your core competency, then you might as well move on to something new because you are already doing something that has already been done.

For us at Open Mountain, we often suggest patterns for development, right after we make sure we understand what your business is about. Patterns have nice benefits that we like to use to take the risk out of development.

(I posted this originally on May 25, 2008 and decided to re-post)