Doable vs Shippable

All the hubbub about flash support on the iPhone highlights an interesting “gotcha” that many people fall into: there’s a world of difference between having something running and having something you can actually ship. The funny thing about software development is that it is generally much quicker and easier to solve all the “hard” problems and create the software you need than it is to polish off all the little loose ends that turn code into an actual product. It’s also surprising how many ideas that sound really good on paper turn out to actually make things worse.

For example, recently I spent an evening and developed a fairly basic image editor that could plug into EditLive!  Just the basic operations like crop and resize that people want to quickly do without switching to a separate program. It took all of about 3 hours work and dealt with error conditions, was well coded etc etc etc. Of course, the UI was hideously ugly because I didn’t have any icons to use and it wasn’t my primary focus but it was an impressive, if ugly, little program. The trouble is, it will take a month or two of full time effort to bring that program to a point where it can really be shipped to our clients. There are just so many little details you need to consider that aren’t obvious until you’ve gone through the process a few times.

There are also times when you develop something, sort out all the loose ends and are really ready to send it out to the market, until you realize it sucks. I spent some time a while back improving the standards compliance of the caching we do in EditLive! It basically cached everything and ignored even the basic Pragma: No-Cache directive which does cause issues for a number of our clients so it seemed like a no-brainer to fix. The trouble is, far too many servers and developers default to disallowing caching even when the content isn’t going to change. This has a fairly minimal effect on browsers because you don’t go back and forward through pages all that often so the site feels a bit more sluggish but it’s not too distracting. In a HTML editor, you want the images to be cached, no question. The number of times the document changes around, when you cut and paste that image etc etc you really don’t want to have to download the entire image again – even more so if the image size isn’t specified in the HTML since then the document content jumps around when the image finally does download. It turns out you have to be pretty clever in how you apply the caching standards in a HTML editor – they do work, it’s not that the standard is wrong, it’s just that it takes a lot of careful thought to get it all right.

So how does this relate to Flash and the iPhone? There’s a couple of ways – firstly, let’s say Apple has the full Flash running on the iPhone with no bugs etc. How fast is it? If it’s too slow, users might be better off with the non-flash version that any decent site should provide. How much battery power does it drain? This is your phone we’re talking about, having it run out of battery during a day is a major inconvenience. How well does it interact with the iPhone’s touch screen input method and the on-screen keyboard? I keep hearing people argue that the iPhone needs flash so it has access to all those little flash games around the internet. You know, the ones where you move with the arrow keys…. oh wait. Sometimes things aren’t as straight forward or as cool as you think and you probably won’t know until you’ve actually tried it.

The second question is whether these rumours of Apple having flash running on the iPhone are actually people seeing the mobile version of flash which Jobs mentioned and discarded as too simple for the iPhone. Mobile flash isn’t being kept off the iPhone because of technical limitations, but because, at least according to Jobs, it’s simply not good enough to handle the real internet. It’s also not necessarily a step forward to add mobile flash, even if it can’t handle everything. All those sites that do the right thing and provide fall back content automatically if flash isn’t available work just fine on the iPhone right now. If you have mobile flash though, suddenly they’ll be showing you the flash content and if mobile flash isn’t up to scratch it just won’t work. Sometimes adding features winds up making things worse.

What’s the bottom line? Whenever you hear someone talk about how easy it would be to do something, ask them if they’ve actually done it. If not, there’s a very good chance they’re wrong, regardless of their qualifications and experience. Really, really smart people hit unexpected roadblocks every day so unless you’ve actually achieved something you should be expecting unexpected trouble. Secondly, even if they have proven it can be done, check that it actually works out as well as you’d expect in real world testing. The real world is full of surprises and some of them will almost certainly apply to what you’re working on so be prepared.

Of course, this doesn’t just apply to flash or the iPhone, it applies to all engineering work that tries to achieve something new. Just remember, if it were simple, someone else would have done it by now.