Companies are finding real benefit from starting on a platform that provides functionality and existing customers. More and more developers are launching products on the iPhone, facebook and SalesForce. We definitely encourage our customers to use existing technologies and services to expedite time-to-market.
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.
