How We Built a Google Calendar Undelete Tool in Four Days

This guest post comes from Mike Pav, Engineering VP for Spanning Cloud Apps. When not running marathons, or tending his raised bed gardens, Mike spends his waking hours focusing on how to reliably and repeatedly build products that delight his customers.

Many electrons have been consumed talking about the business and technical benefits of moving to the cloud.  At Spanning, we try to apply those same lessons to our daily work in order to produce products at a pace that was not even feasible back in the packaged apps days.  This post discusses how we can quickly make imperfect decisions now, that allow us to move forward, learn a little more, then re-evaluate the next set of issues with more context.  This is the same model that companies use when they move to the cloud... only pay for the services that you need now.

Two of the major decisions (well, engineering based decisions... Marketing has a whole other set of criteria) that we take into account when scoping a Free Tool are:

● It must be technically feasible, and ideally leverage code and knowledge that we already have.  Since we don’t want to expend a ton of engineering time on a Free Tool, we need to be very efficient with our implementation.

● It must address a real world need.  One thing that engineers hate more than anything is building a product that no one uses.

Calendar Undelete clearly meets these two criteria.  So we set aside some time on the schedule and pulled the whole engineering team into the project.  We initially scoped out the following requirements:

● Must be installable into a Google Apps Domain.  We do this because it provides immediate access to all domain users once an Admin has installed the app into their domain.  We have deep experience with the 2 Legged OAuth (2LOA)  flow and Google Apps Marketplace listing process so this should be a real no-brainer...

● Must be able to consume a user’s Google calendar Feed.  Deleted events are not immediately removed from a user’s calendar feed.  Instead, they are marked as “cancelled”.  We have an existing Google Calendar Feed V2 implementation, so again this should be easy...

● Must be able to undelete a set of deleted calendar events.  Again, since we have experience with restoring calendar events as part of our Backup product, we know that this is tricky, but doable...

So, we get down to work and the first thing we realize is that this tool will have broad appeal to individual users as well, so we need to support a normal (aka 3 Legged OAuth) (3LOA) security model.  Our existing 3LOA implementation uses OAuth Version 1.0, but we quickly decided that this is a great opportunity to stand up an OAuth 2.0 service since that is a much cleaner User Experience and API.  Yikes, now we are into the land of the unknown.... lets timebox this effort and see what we find.

While diving into the OAuth 2.0 implementation we also decide that now is the time to investigate Google’s new Calendar API V3 because it provides the ability to “PATCH” an existing event, effectively allowing us to restore a “cancelled” event simply by updating the event’s status field to “confirmed” rather than recreating the whole event.  This removes all the complexity of the old V2 model of needing to create a new event and keep the parent-child relationship of events intact.  We quickly confirm that the new V3 Calendar API supports both 2LOA (using OAuth 1.0 if you really want to know) and 3LOA using OAuth 2.0 so we commit to this approach.

From a User Experience perspective we know that we need to support multiple pages of deleted events and allow users to restore one, some, or all of their events.  These interactions should be fast and provide accurate feedback.  This drives our implementation down the path of caching the full set of deleted events for a user on first load of that calendar so that paging (and column sorting) is fast.  Just because the tool is Free, does not mean it should be cheap!  At first the need to cache deleted events seems like it is going to be a costly effort, but we again timebox some prototyping effort and find that there is an easy way to lazily manage expired cache content.

So, in the course of this one Free Tool we make several fundamental technical changes along the way.  This might sound crazy to those of you who need to scope a whole project out before getting started, but this approach is core to how we work at Spanning.  We only make hard decisions based on what we know now.  We take risks and evaluate their benefit and cost continuously so that we can quickly know when to commit or roll back.  In a future blog I’ll talk about a technical decision that did not turn out as well as this story.

Oh, and did I mention that from inception to delivery we spent 4 business days?

Be sure to read the next Business article: Local Corp. Uses Krillion API to Grow in New Markets