A few months back, we were proposing to build a facebook application using some other technologies as well.  In our proposals, we like to think ahead to point out issues that could arise and we stated that any changes to these technologies could impact the schedule.  At this point, the customer emailed me an interesting question.

How do we mitigate the risk if facebook or the other technologies change?

Our customer was asking a pretty good question.  If facebook changes their API or markup language, we may have to re-factor significant amounts of code.  Don’t think this could happen?  It already did.  Here’s how it impacted some developers.

At first I was tempted to say that is the nature of the beast.  If you are building a house and it starts to rain, construction will be impacted.  Materials will get wet.  You might have a major disaster if you just poured the foundation and the cement hasn’t cured.  We can’t stop the rain.

I then realized this is a profound question and that I needed to give it some thought.  We develop for start-ups all the time and a significant delay from outside influences could prove disastrous.  I started thinking through the possibilities.

First, we need to consider if companies we are depending on actually appreciate this risk.  How often does the facebook API change?  How does SalesForce improve their platform without breaking existing applications?  It’s reasonable to conclude that if Apple, facebook and SalesForce care about their business they wouldn’t adversely impact people making a living off their technology.

I did a little investigation to see how well these companies keep their developers informed of changes.  Everything I discovered was as of the writing of this post and may have changed before publishing.  I certainly welcome anyone from facebook, Apple or SalesForce to comment on this post and provide information I may have missed.

facebook clearly embraces developers as a community.  Their WIKI is comprehensive and includes a link to view the latest changes to the platform.  A proactive developer could sense changes were in the air for sure.  I was hoping to find a way to subscribe to emailed changes.  I’ll keep looking for that.

Apple’s developer site feels very polished.  They clearly focus on information presentment making it easy to find documentation.  That said, the site seemed to offer less insight into what is happening with the platform.  By way of contrast, WIKI community sites are easy to edit and therefore updated more frequently, but often contain posts that are not completely accurate or have become out of date.  A good editor solves this problem of course.

SalesForce.com is definitely going the community route.  The developer site includes documentation, news, events, updates and discussions.  An active developer can stay abreast of changes for the most part.  After looking at the site, you can see that the company is making a good effort to keep the developer community informed.

Back to the question, how can we mitigate the risks of a key technology or platform changing mid-cycle?

Here are some the techniques we recommend for staying informed and managing the risk from developing on existing technologies and platforms:

1) Subscribe to all change lists – The best way to find out if an API or technology is changing is to have the company tell you in advance.  Trust me, you don’t want to find out from users your site is broken.

2) Avoid developing functionality that has a shelf life – Some times, it is clear an API or functionality may have limited long-term viability.  Certainly privacy and security issues won’t stand over time on any site with significant usage.  Developers love to exploit a loophole or over reaching function.  Your business might be doomed if this loophole is core to your success and it gets closed.

3) Plan for scenarios in the business – The corollary to point 2 is plan for the unfortunate or unexpected.  You should certainly utilize any advantage you reasonably uncover.  Just don’t bet the farm on anything that may pose a long-term issue for the platform without a backup plan.  Spend time thinking about how your business would need to adapt.

4) Create a business that is truly platform independent – Try to see each technology used by your product as a component instead of a necessity.  facebook could be swapped out for MySpace or Twitter for example.  If you use an open source product for your shopping cart or CMS, consider having a backup choice in case you find a bug that can’t be fixed.  Ask your architect to present an alternative technology stack that changes all third-party technologies just to prove it can be done.

Experienced teams use existing platforms and technologies to enhance products, speed up development and create forward-looking solutions.  You should too!  Just don’t get caught depending on something that would hobble your business if it changed.  Have a plan to get back up if the rug is pulled out from underneath you.

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)