Agonies of Programming for Facebook

We've built our share of Facebook apps and formatted a few fan pages and, as with any technology, it's a moving target. What worked last year doesn't work today, and who knows what will work next year.

The problem is that Facebook's programming environment seems to be moving like John Cleese's Silly Walk -- it bobs and jumps and swings and you never know where the next leg is going to go. As soon as you think you have something pinned down, it flies off with an amazing angle and speed.

And we just found something new… I assume in their attempt to solve the horrors of a rapidly changing programming environment, they have quietly been letting old developers continue to use the old programming interface, so when we developed the app on our development account, the tools didn't match the new page our client had set up and huge chunks of code were broken.

Not that Facebook documents this, so we only found out when we moved it to the new account.

The problem with this whole 'app' thing (Facebook, iPhone, Kindle, droid… the list keeps growing) is that you have to keep current on your core programming language AND the changing whims of corporate 'standards' that have less to do with functionality and more to do with who's suing the corporation this week.

Facebook has played with the way the Like button works more times than… (let's just assume I have a really dirty joke to go with that phrase). Last week we were able to force people to Like something to see some content. Last week Facebook announced new Like button behaviors, and suddenly the thing doesn't work in the new environment (still seems to work on our old implementations, though).

But there's this kind of investment roulette going on here -- our clients are paying us good money to build something that, honestly, has a lot of uncontrollable variables. Whether it's Facebook unceremoniously breaking things that we slowly crafted, or Apple removing an App from the store without comment, these arbitrary decisions are costing us time and money.

I don't have to just worry about hiring programmers who know what they're doing, now I have to worry about some six degrees of Kevin Bacon's IT Staff -- a programmer in Fremont decides to 'clean something up' in the API, or a lawyer in LA says, 'we gotta make this go away' or a sales person in New York says, 'we gotta change that.'

Kind of like trying to manage by the same principles of social media -- random crap taking you by surprise…