Lost in LoC

Over the past 7 weeks I’ve been working on a project at work called MashedIn. The goal of the project is to provide social context to otherwise contextual-less online media. For example, pretend I write a blog (which I do… somewhat… kinda…). Using MashedIn I can put a widget on my blog which allows the visitor of my site to see how he or she is connected to me through Twitter, Facebook, and other social networking services (some coming in the near future). This may seem like something trivial (note: it’s not), and on the outset it may seem like something that provides very little value (note: not true), but the fact is it can be a tool of great power when used in the proper setting.

That proper setting is locality. If your’e reading my blog chances are you don’t know me. About 90% of my hits come from a few keyword searches and Google. If I had the MashedIn widget on my blog, and you actually decided to see what it was all about, you’d likely be quite disappointed because – well – we’re likely in different cities, if not other countries. However, imagine you’re viewing the website of your local butcher shop and they have the MashedIn widget on their site. You may have never done business with the butcher shop, you may not even know that the butcher shop in question works only with lamb (they really love their mutton), but by signing into the widget you suddenly realize that you know a few people that work there, and you have several mutual friends. Suddenly you have a boatload of people you can ask about this butcher shop.

That functionality may still sound trivial, but if you start with that foundation the power and complexity that may be provided to you the visitor can suddenly ramp up, especially if you integrate the mashed social graph with other online crowdsourced services (such as StepRep‘s recommendation system). Out of the box the widget doesn’t seem very impressive, but we’re only 7 weeks in and we have a huge backlog of ideas that can make this thing pivotal to bloggers, local businesses, etc.

We’re developing MashedIn 1 week at a time (each week named after the element with the corresponding atomic weight). Every Friday morning we plan what we’re going to do for the following Monday through Wednesday. Every Thursday we wrap things up; do one last round of integration, testing and debugging, and then release. The velocity is high and the focus intense. Lots of fun agile practices such as Test Driven Development, pair programming, etc. But more importantly there’s lots of interesting challenges to be solved.

In the 4th week of development (named Beryllium because Beryllium has an atomic weight of 4, you getting this now? Yea, nerdism at it’s best) some pretty bad design decisions were made regarding how we manage all the different social networks MashedIn works with. We spent a bunch of time on the 3 subsequent sprints (Boron, Carbon and Nitrogen) fixing these decisions, and we’re finally at a state that we’re content with… for now. This exercise has been interesting, however, and has proven what we all heard in first year comp-sci: The most expensive part of software development is adjusting code that’s already been released. Keep in mind we spent 1 week (3 days, really) back in Beryllium to write the code that’s pivotal to handling MashedIn’s core system. The design was so poor that it cost us the lion-share of Boron, Carbon and Nitrogen to fix. That’s some rather hefty opportunity cost to pay for not having spent a few more hours group-thinking about a better solution. Thankfully we can finally move on and get back to concentrating on some of the more interesting problems.

Monday marks Day 1 of Oxygen (our 8th week). This sprint’s theme is more consistent and user friendly session management with our various social partners. This is a complicated task because Twitter’s implementation of OAuth is significantly different than Facebook Connect, and who knows how that is different from all the other social networks. We’ve developed patterns over the past few sprints which have significantly improved the experience, but there are still some gotchas that need handling. How do we gracefully handle an expired session, especially since that session is outside of our control and can literally expire at any time? What do we do when a visitor is looking at a widget and the owner of that widget has failed to allow for Facebook’s persistent permissions? How do we balance what the visitor of the site cares to see and do vs. the system’s requirements to do all that crazy processing (thus requiring special permissions from the owner of the widget)? It’s an interesting mix of challenges, and I look forward to seeing what we come up with next week.

Until then, The Dude abides!