What is the Proper Balance?

A bane (or boon, depending upon your perspective) of being a software developer is that nothing ever stays the same.

Ever.

Master one development tool, and version n+1 is released.  Reach Nirvana as a the guru of a particular methodology, just as it is consigned to the dustbin of development history.

This is simply the nature of things.

However, sometimes remaining stable and unchanging for long periods of time have tremendous upsides; for example, I wrote an Electrical Contracting package under MS-DOS in 1988 that was still in production in 2008.  I’m sure there are some Cobol programs out there with even longer longevity.

Somewhere, there is a happy balance between obsolescence and jumping to the next flavor of the month because it is the flavor of the month.

What is the balance?  Does it have to be measured in years?  Or should innovation and progress always trump the investment of time, resources, and capital made in a technology, a platform, a language?

I believe that the answer lies in gauging the amount of change your audience / customers can tolerate, versus the pain that the people who have to support and develop the infrastructure of that change must undergo.

For those not invested in the incoming new regime of any change, it is a tremendous opportunity to jump in and gain traction against slow adopters. For those invested in things as they exist now, they are burdened with support of the existing AND the creation of the new… often at cross purposes with regard to marketing and existing sales (see the history of Osborne Computers, and the existing saga of Windows Mobile 7 for a contemporary example).

Of course, the only pragmatic solution is this: sack up.  If you want to remain relevant, you’ve got to innovate along with the market.

Nobody ever became prosperous making political statements regarding software development.

Internet famous, certainly.

Prosperous?  No.

So, as Facebook abandons everyone who ever used Facebook Connect, all I can do is grin and bear it and enjoy the opportunity to re-do months of work across multiple platforms to support this new direction with Open Graph.  For legions of Windows Mobile 6.5 app makers, they are preparing to scrap all of that in order to move on to Windows Mobile 7.

Adapt or die.

But it would be nice to see the day that something I created on Facebook had a lifetime beyond a handful of months before the platform entirely changes beneath our feet.

Innovation for innovation’s sake is one thing; planned obsolescence is another.

The Agency “Circle of Life”

A friend of mine and I were discussing how everyone we ever knew who worked at a big agency never stays put for longer than a year of so at a time.  It’s a tough business, and one in which forming lasting relationships and finding “real” performers is tough to do.

One of the givens is that stellar performers will one day determine their true worth and will leave for greener pastures, or strike out on their own as a competitor.  It’s the Agency equivalent of “The Circle of Life.”

What always seems humorous (at least to me) is when Agency principals take offense to this, or better yet, try to enforce a workplace atmosphere to keep this from happening.

What’s funny about it?

Because at one time, the very people who are trying to keep star talent from bailing and going out on their own were once just like the people they’re trying to thwart from doing the exact same thing.

What is so ironic, is that most agency styled consultancies tend to pump up the fact that their talent is what sets them apart… yet they don’t want their talent to become “too talented” – if you catch my drift.

Really, the only curative is that if you want to retain your All-Stars, is that at some point you’ve got to give them some real reasons to stay – stock, options, equity, skin.

Otherwise, you’re only fooling yourself that you’re gonna keep the talent “down on the farm.”

For a good example of how not to handle this scenario, I offer up this chestnut.

Facebook’s New OAuth 2.0 Authentication and Android: Ruh Roh!

Facebook is about to sunset (abandon) Facebook Connect, forcing developers with working apps and sites to do everything all over again.

It would really be nice if they bought us dinner first.  But I digress.

One casualty of this change early on is making Facebook OAuth 2.0 authentication scheme work on Android.

Or not, as the case is proving to be.

If you’ve written an OAuth implementation on Android, more likely than not you’ve used a library like signpost and implemented a custom protocol to direct your callback to an appropriate intent in your application to handle the callback package.

Except that apparently Facebook only recognizes http and https as “legit” callback protocols.

In short, for the time being, those of you looking to do an Android version of the new Graph API and FB OAuth 2.0 scheme are hosed.

Big Moves

With the announcements last week from Twitter (acquisition of Tweetie and announced intentions of additional mobile space moves) and the information dumped this week from Facebook F8 (Dropping of Facebook Connect Branding, new APIs, Credits, removal of the 24 hour limit for data retention, etc.), one wonders:

How do these big moves affect you?

As a user, in many ways this means that your user experience across a number of your favorite sites will become more integrated.  It will also mean that things you thought were “private” aren’t really.

I think the fallout / shakeout from these big moves will become crystal clear over the course of the summer as startups and companies adapt to the changing landscape.

As a developer, these announcements provide an opportunity to differentiate and innovate.

But at the same time, the announcements are a continuation of a recurring theme at Facebook, particularly with regard to its API and application development – namely, Facebook’s constant changes means your implementation work is never really done and every six months or so they’re gonna break your shit.

Place me squarely in the “let’s see how this really shakes out” camp.

I’m less than enthralled with the prospect of so much having to go through a single gatekeeper, benevolent or not, who may decide to capriciously cut me off from the trough, on a whim.  In the case of Facebook, they’ve yet to prove that they can reliably be trusted with this type of stewardship.

So, hunker down and prepare to hear  an avalanche of gushing about how Facebook is going to “change the game” and how Twitter is “getting serious.”

And be sure to set your B.S. filter to “high.”

Big Time Bug in Facebook Connect for the iPhone

While working on a new app for a client in Orlando today, we uncovered a significant bug in the Facebook Connect classes from Facebook for the iPhone.

What’s the bug?

Well, if you’re one of the fortunate souls who have a FB user id larger than an int, FB Connect for the iPhone, as it comes from Facebook, will blow up.

Blow up REAL good.

Oh, it may authenticate. But just wait till you check the uid in the session.

HEY! It doesn’t match my real uid!

The big bug is this – the FB Connect code uses library methods meant for integer values… all the while preaching to everyone the importance of Facebook User IDs being 64 bit values; in other words, in Objective-C parlance, long longs.

Too bad, ’cause with FB Connect for iPhone what this turns out to be is “do as I say, not as I do.”

Here’s where the busted code exists in the FBConnect code, and what needs to be done to correct:

FBSession.m

in the -(void)save method, replace the line that has [defaults setInteger:uid] forKey:@"FBUserId"] with the following:

[defaults setObject:[NSString stringWithFormat:@"%qi", _uid] forKey:@"FBUserId"];

in the -(BOOL)resume method, replace the line that has FBUID uid = [defaults intForKey:@"FBUserId"] with the following:

long long uid = 0;
NSString * uidString = [defaults objectForKey:@"FBUserId"];
if (uidString!=nil) {
NSScanner* scanner = [NSScanner scannerWithString:uidString];
if([scanner scanLongLong:&uid] == YES) {}
}


For all the razzing I’m giving Facebook here, really the broken parts of the classes are centered around moving data in and out of the settings bundle. Yeah – the uid’s are integers – big ass integers, to be sure – but the int functions for the settings bundle are no good for long longs – you got to convert them into NSStrings, and then back to long long again (%qi in sprintf-speak) when using the bundle functions.

Hope this helps those of you trying to explain why your iPhone apps work most of the time with Facebook Connect.

Sometimes, it really isn’t you – it IS the software (with apologies to Nick Burns, the Computer Guy).