Developing on a Platform Creates a Dependency

November 2, 2009

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.

Leave a Comment » | Development philosophy | Tagged: , , , | Permalink
Posted by bbenedict

Rails Conference 2008

June 3, 2008

I recently attended the RailsConf 2008 in Portland Oregon. The conference is sponsored by O’ Reilly and is one of the premier events for the growing Ruby on Rails solution. The Ruby language with the Rails framework is definitely gaining significant momentum. To me, this is clearly the next Java or C++. It is quick and effective for creating Web applications and developers love it. Someone once told me that motivated people working with technologies they like make the best products.

I was impressed by the sessions at this conference. The technical speakers were informed and clear. They were primarily experienced based speakers which means their knowledge was born from hands on work. I find people working in the field are more interesting, relevant and accurate when compared to those talking theory. Really, if you are considering developing in Ruby on Rails, I highly recommend you attend next year.

Joel Spolksy was a great keynote speaker at the conference. I remember laughing a lot and feeling like he had an interesting point of view for his talk. He really had a laugh at the expense of Windows. Funny that Bill Gates, in an email to his people, did not find the Windows usability thing all that funny. He should have heard Joel go through it as he struggled through patches, reboots and warnings just to upload some photos from his camera.

Overall, Joel made salient points about providing good feedback to users, keeping them in control of their experience and obsessing over all aspects of the experience. To me, this was a great statement about the whole “put it out there” movement in startups driven mainly by facebook applications. Yes, it is good to get user feedback sooner rather than later, especially before embarking on a mammoth development effort. But don’t sell yourself short by releasing a product that could be better with a little more effort and time.

I had mixed thoughts about the keynote speech from David Heinemeier Hansson. Ruby on Rails is truly an innovative combination. Before I give you my opinion of the talk, let me give you some analogies for what I think is innovative.

Developing in RoR is like building a house for the first time using a nail gun instead of a hammer. It’s like the first time you drove a car with power steering and power windows. It’s like the first time you created a server side product using Web technologies where as before you had to write code to handle requests, package data, manage connections and all that ugliness. It’s like the first time you took a flight from SF to LA when you used to drive because you were in college trying to save money. It’s like…(had enough???).

David is the founder of the RoR movement. He talked about the surplus created by having a superior tool as something developers should take advantage of for personal improvement. On the whole, this is not a bad concept. David felt that developers should use the time savings to sleep more, learn to whittle or even to fly a plane. Yes, it was mostly a humorous point. Our engineers should use the fact that they have a “better, faster tool” to take time to smell the roses.

However, in my opinion, this works against why Ruby on Rails is one of the fastest growing technology movements around. People are switching to RoR because it is faster. There really isn’t enough evidence yet to say it is better than other choices like Java with Hibernate and Spring or PHP with CakePHP. The surplus time should be used to extend this advantage and get more people and companies on board. After all, who would you hire to build your house? The guy swinging an old hammer or the guy with the nail gun and power drill? And what would you think if the guy with the power tools took a nap every day on site because he knew his tools were faster than the way they used to build houses? See my point?

The reason this language is selling today is exactly because of the faster angle. If you take that away, then you don’t quite have the history and track record yet to stand up against more established technologies. You have to get over the tipping point a little and then you can take a snooze.

Before I forget to mention it, Portland, Oregon is one rocking town. If you believe the whole “smell the roses thing” that David was emphasizing, I recommend you do it there at around 11 PM on a Saturday night. I know this has very little to do with the conference. Still, I have to give credit to the conference organizers for picking a cool location.

One goal for myself at the conference was to gather information about RoR scalability issues. I can now say that I am not worried at all after listening to a panel discussion from a group of guys responsible for about 4 billion Ruby requests a month. Representatives from EngineYard, Rails Machine, LinkedIn and AOL talked through their experiences taking RoR to the max. The big take away is that people need to think of scalability in terms of the entire system. The best coders in the world can’t make poorly designed data objects or under-powered hardware go any faster, for example.

We heard a keynote talk from Kent Beck later in the week. Kent is the visionary behind many innovative ideas including Test Driven Development and Extreme Programming. I recommend you Google Kent Back then read a lot about him and his ideas. And buy his books too! But make sure you form your own opinions which I think is his real goal for everything he creates. What is super impressive is how Kent sees the big picture, long term stuff. He talked about how real change, or rather the true fruition of his creative ideas, takes on the order of 20 years to go from concept to accepted practice. Talk about a visionary! Good call on Test Driven Development Kent.

In the end, I walked away from the conference convinced more than ever that Ruby on Rails represents a next generation approach to scalable Web development. I am a true believer after listening to a dozen sessions on various topics including scalability, project management, lessons learned from Web application development, complex searching and others. But the strength of any tool is in the people who use it. After all, a good carpenter is just as effective with a hammer as a nail gun.

Leave a Comment » | Conferences and training | Tagged: , , , , | Permalink
Posted by bbenedict