Adobe: 7 Things You Should Do With Flash/Flex

Dear Adobe:

Apple has started the anti-Flash/Flex snowball rolling, and it is getting steadily bigger.  It’s a perfect storm, because they’ve got the platforms that are perfectly suited to Flash, their platforms are wildly popular, and your faithful audience desperately wants to be there.  But that’s not all.  They didn’t just prohibit Flash, they have called a lot of attention to a credible competitor: HTML5.  I know, I know.  It will be a long time before HTML5 is everything Flash is today.  It’s not even close right now, and a lot of people have conflated media delivery with Rich User Experience in ways that unfairly diminish your platform.  Get over it.  Economic pressures (aka naked greed and envy to be on these precious Apple platforms) have created a hill of growing height, and the water that is developer mindshare is rapidly flowing down that hill and away from Flash.

What can you do?

Lame ads won’t help.  Complaining about it won’t help.  Technology and innovation can help.  If you move quickly, and you have some things in your camp that buy you time (Android), you can still salvage the situation.

Here is what it takes:

1.  Absolute Single Minded Focus on Performance and Stability

People have concluded your platform is buggy and slow.  It doesn’t matter if you agree or not, the customer is always right.  When you hear McAskill at Smugmug and Adler at Scribd railing about your stuff, it’s time to move from denial to acceptance.  Their voices and those of many others are too loud and being spread too efficiently to pretend it isn’t so.  It’s past time to deal with it, in fact.  You need to embrace this problem, own it, and deliver the solution as quickly as possible.  The solutions can take many forms.  My recommendations are part of this post, and this point is more about declaring a focus both publicly and internally and owning the problem.  You don’t have to say, “We agree, our platform is slow and buggy.”  You do have to say:

“We have a great platform and our customers have told us to make it dramatically faster and more stable.  That’s our #1 priority, and here’s how we plan to do it…”

2.  Stability:  Quality + Security.  Get a Czar.

I’ll define Stability as consisting of equal parts Quality and Security.  Your customers are finding too many bugs.  There are too many public security issues.  This is happening at a time when you can ill afford it.  Get a Czar nominated and equipped to deal with this area.  Apportion your development cycles between performance and stability, give the stability cycles to the Czar and just do it.  The Czar needs to rapidly do the following:

– Identify the most egregious problems you have missed that are troubling your customers.  Look outwardly not inwardly to find them.  Fix that first tranche rapidly.

– Upgrade your automated testing so regressions are under control.

– Put in place a culture of quality that ensures that every single release is better than the last one.

– Investigate whether some of the quality issues don’t stem from education issues.  If customers are approaching it wrong, or don’t know how things work, they may be seeing behavior that is exactly what’s expected, but that looks to them like a bug.  Do not let this be an excuse for thinking you don’t have real bugs too.

– Be transparent about the plans and the results.

Get this stuff fixed and make sure it stays fixed.  This is not a, “Let’s fix the top 100/1000/or whatever bugs,” thing.  It’s a cultural change accompanied by results.

3.  Build a High Performance Native Compiler

Yes, I know, it is wonderful that Flash programs work everywhere.  But you are dealing with Performance perception and a company that says they will only let Native tools in the tent.  Figure out how to kill both birds with one stone.  Every platform does not need a native compiler.  But, if Facebook can afford to build a PHP compiler for performance sake, you definitely can afford to do this.  If you don’t have any serious compiler gurus, get some on board.  While you’re at it, build an optimizer for your interpreted stuff too.  You need a two-pronged attack:

–  Better bytecodes with the usual optimizations that matter closer to the language–operator strength reduction and all that.

–  Killer native compiler that will run circles around your bytecode stuff when it needs to.

If you do it right, it should be possible to pick and choose which classes are native and which are bytecode within the same Flash app.  You will also need to provide infrastructure that makes it easy to serve up the right native version to whatever platform is being used by the consumer.  Don’t make your developers figure that out.  BTW, you need to get this into Beta in less than 12 months.  You don’t have much time.

There is an old saying, “If you want people to make a new decision, you must give them new information.”  This pair of developments is the new information for performance haters.

4.  Revisit the Asynchrony of Flash and Embrace Multicore

This may just be baked too deeply into the programming model, but it sucks.  Sometimes programs want to be able to block until something happens, and when they can’t they wind up wasting their time and you mobile device’s battery life to no good end.  This asynchronous stuff is a throwback to not having a real multi-thread model for Flash, and in the Multicore Era, that’s a liability.  Sure, current mobile platforms don’t have many cores.  It doesn’t matter.  #3 is really only a stopgap.  In the Multicore Era, if you want to completely crush the competition on performance, do it with more cores.  When I was at Oracle, it was all about building benchmarks that could use more cores than SQL Server.  Once you use more cores than the other guys, you become almost exponentially faster.

And while you’re at it, you will deliver a model that is much friendlier to developers.  Being able to deal with multiple threads and blocking should be the basis for Flex 5.

5.  Embrace the GPU and Knock ‘Em Dead With 3D

Last point.  For most machines, the graphics processor is the most powerful CPU in the machine.  That’s a big surprise to many, but hey, it’s true.  That sucker has got vector processing going on just like the old Cray supercomputers.  There are companies building supercomputers out of them, for Heaven’s Sake.  Our freakin’ Air Force uses the GPU’s in Sony Playstations to build supercomputers fer cryin’ out loud.  I know it is a pain to go native on the GPU.  Sometimes the OS doesn’t help you very much.  But you have to find a way to get your developer’s hands on those beautiful MIPS.  This is especially true since Flash is all about the visuals.  While you’re at it, build a killer 3D subsystem for Flash so peeps can create virtual reality, 3D modelers, CAD/CAM, killer FPS games, and a whole of others things you haven’t even thought of.  With #’s 3, 4, and 5, nobody will be able to touch you on the performance front.

6.  Bring Back the Flock with a Cross Compiler

In many ways, Apple’s insistance on anything but Flash is like an old-fashioned shelf space war straight out of the pages of Ye Olde Shrink Wrapped Software.  If I build my app in not-Flash, it is a pain for me to go back to Flash no matter how much I like it.  It is worse if my not-Flash is on a super hot platform, because I kind of want to just keep writing not-Flash on that platform once I get hooked.

Here is the thing: if HTML5 is really as limiting as Flash devotees claim, it should be trivial to translate the limited functionality of HTML5 to Flash.  While you are at it, please undertake the slightly less trivial task of moving Objective-C to Flash.  Sound hard?  It is a little, but not any harder than all the other stuff you need to do.  Besides, I’ll bet you can do this one as a joint project with Google.  Why?  Easy:

Take any award-winning iPlatform app.  Feed source into your new cross compiler.  Push a button.  Get back an award-winning Android app written in Flash.  BTW, you can have it on your desktop or anywhere else too.

Now what iPlatform developer could resist that if it all works great?  Don’t think of it as aiding the enemy by giving developers an opportunity to start from HTML5 with less downside.  The developers that will use this are already lost to you, and you need to bring back your flock.

7.  Keep Your HTML5 Powder Dry

By now Adobe, I expect you’re really feeling pretty unhappy with this post.  The stuff I am telling you needs to be done is not easy, and it won’t be cheap.  At the same time, you know in your heart that this is what it really takes to win this war.  It’s about to get worse.  HTML5 is coming.  All of those other steps will only allow you to maintain your lead for longer.

You need to recreate everything that is great for your platform on HTML5.  But, you need to keep it in the backroom until the timing is right.  Don’t dribble it out.  Do big quantum leap releases.  Your first one should not be an also-ran.  It should establish Adobe as the premiere resource for HTML5 developers.

It’s just that simple

As I’ve said, this is a hard road.  But, if you don’t follow it, if you don’t dig down deep and go to war now in a meaningful way, you won’t catch up later.  You’ve got a great platform.  If you want to keep it, you know what to do.