Biggest Post Ever Redux: NoSQL as a More Flexible Solution?

Thanks to Reddit, HackerNews, and a host of other sources, my post on NoSQL being a Premature Optimization just became the biggest post ever for Smoothspan Blog.  Thanks to all for reading!

I’m actually surprised at how little argument the post has gotten.  The best comeback has been that NoSQL is not just about scaling.  You can see some of that sort of response in the comments for the original post.

The “it’s not about scaling” argument boils down to it being easier to model some kinds of problems with NoSQL than Relational because the tools and model are more flexible.  To this, I can only respond, “yeah maybe, but was modelling really the hard part of what you’re doing?”

I’ve modeled a lot of things in relational.  Some of them were very arbitrary and had little to do with the hardcore relational way of thinking.  Come to think of it, most were pretty arbitrary.  More than one commenter suggests that the existence of object relational mapping layers is a clear indication of how painful relational can be.  But it sure doesn’t feel that way if you’ve done a lot of it.  Seems like the usual sort of shoehorning some arbitrary notion into a data structure that we deal with all the time in Computer Science.  There are lots of good proven tools for it.   I’ve built mapping layers too and even that wasn’t all that hard.  Adrian Cockcroft from Netflix left one of the very first comments and suggested it was hard to beat the productivity of Ruby on Rails with MySQL for a small team.  That’s a case where the mapping layer became integral to the fabric of the framework, and one I’d love to see happen more often given how fundamental persistent storage is to a lot of problems.   One could even argue it is the fundamental thing that sets Ruby on Rails apart was making persistence a first class problem they wanted to solve up front.  Maybe there is another Ruby on Rails success story just waiting for a NoSQL tool to get crossed with some up and coming dynamic language.

Go back to my original post on NoSQL and go through some of the Netflix materials.  Some of the problems they had to solve in NoSQL are modeling problems there too, BTW.  The difference is that the warts and edge cases for relational are pretty well understood by now.  You don’t have to invent your own solutions (as the Netflix people did for things like NULL handling)–there are 6 or 8 out there just waiting to be Googled to choose from.

But this all ignores my question about whether modeling was really the hard part.  I don’t think it is, though developers love to think about the up front “minimum best fit to their design vision” as the hard part.  Having been through 6 startups now, the hard part is all the stuff that isn’t written down.  It’s the problems that pop up when things just don’t work, don’t work as expected, stop working, work too slowly, and generally just piss you off for no good or predictable in advance reason.  They pop up in the middle of the night, late in the project, after customers get hold of the software, and when there is no turning back.  They show up in spades when you hire new people and don’t have time to train them, so they just have to figure it out on their own.  Such problems extend far beyond mere development of a prototype and will in the ops and day-to-day care and feeding of a successful system.  They are problems born of a lack of maturity.  They get gradually burnished away over time in mature toolsets as bugs are fixed, experience spreads, and patterns and know-how are disseminated to the community.  NoSQL (let alone NewSQL) is just not old enough to be there yet relative to relational.  Give it a minimum of 5 years and more likely 10.  Companies like Netflix are helping make it happen as we speak.  When there are 10 Netflixes that have all built big projects that are wildly different and in total involved over 1000 developers, then we’ll have a start on it.

Meanwhile, you have a startup or a project that needs doing.  If you have a cadre who have already been through NoSQL in a prior startup or project, they may have the experience and scar tissue to make an informed decision about it.  They represent a localized burnishing of the worst problems away.  If you haven’t ever done more than read articles and tinker with toy projects, why would you risk your important project playing around with this new technology?  What do you hope to gain when there are proven solutions already at hand?  Do you expect the Silver Bullet that will magically cut your development time in half?  Do you think your startup or project is so easy you have the luxury to experiment with additional risk?

Interesting.

Have Your Kids Tried Programming?

Each summer we try to arrange that our kids have a mix of fun things and self-enriching things to do.   Self-enriching things are intended to help them develop their talents and maybe get a little better prepared for the next year in school.  If they had some weaknesses the prior year, we’ll have them work on those a bit and we’ll try to get them looking ahead at next year’s equivalent class.  We try to give them some say so on these projects so long as they stick to things that move the ball forward against the original goals.  By way of developing talents, this summer we decided to try programming.

I had looked into the possibility months before and decided Python would be the learning vehicle.  It has a number of charms, seems to be one of the Cool Kids Languages, is powerful enough to do useful work, has a following among educators and so on.  In addition, it had a couple of strong marketing attributes that I think worked well with the kids.  First, they respond when they hear it is one of the languages of choice at Google.  I’ll never forget driving by Google’s offices one day in Mountain View and having my 12 year old daughter beg to go check it out.  I was surprised that a young girl would care about Google, but to her it was a chance to see a very cool thing.  I explained that the campus wasn’t really open and that while there were some fun things inside the doors, it was mostly just offices.  I felt a bit bad for having deflated the dream a bit, but this argument that we’re going to learn Python because it’s what Google uses still carries weight with these kids.

The second key marketing attribute I have made sure to mention and remind them of several times was that I don’t know Python myself.

There’s a psychology to be aware of that I’ve seen before–kids don’t want to compete with Dad once they move into their teens.  They want to win on their own terms, and if Dad seems to far ahead on something, that something is a lot less interesting.  Knowing Dad is a programmer, I initially felt some push back over whether the kids would want to learn programming or not.  But telling them I didn’t know Python and would look to them to teach me about it had the desired effect.  They liked that a lot.

How has it gone?

It’s early days yet, but I have been impressed.  First, I had only assigned this task to my son, but my daughter jumped in almost immediately of her own volition.  Second, they’re chewing through the basics at a pretty good clip and without a lot of help.  Their code seems pretty clean and well structured.  They’re at the stage of basic control flows and seem to get it.  Lastly, without any prompting from me, they’ve naturally taken to using the Internet as any developer would to help answer their questions as they come up by cruising forums, StackOverflow, and a variety of other resources.

I don’t know yet whether my kids will be great developers or not.  I am from the camp that thinks software developers are born and not made.  I have seen too many cases of inexperienced brilliant developers with little or no formal education coding circles around developers with computer science degrees from MIT, Stanford, and other top schools.  Those that have the spark can manifest it at an early stage and grow rapidly from there.  As every father would, I hope my kids can be stars at what their father loves, but at the same time I want them to choose their own way.

Meanwhile, expose your kids to a summer of programming just so you both can see how they take to it.

The 7 Kinds of Software Developer Wushu

James Governor got me thinking along these lines by asking how to segment developers.  He asked whether the web “killed” the professional developer, or at the very least radically reshaped the segments.  I don’t know about all that, in fact I’m pretty skeptical.  But what I do know is that the way James talked about developers didn’t really resonate with me at all.  I’ve been managing developers for 27 years now, including a couple of stints that have involved selling tools to developers (via Borland and my Integrity QA startup, then at Rational/Pure Atria), and I just don’t think of them as “hobbyists”, “enterprise timeservers”, or any of the other possibilities suggested.  Likewise, while I found Coté’s alternative niches vaguely entertaining, they didn’t fit either in terms of providing me a unified field theory of how to think about developers.  Part of the problem is in not defining what the segmentation is for.  When I hear “segmentation”, I think about mapping out a plan to go sell something to an audience.

Putting all that aside, what really was more interesting to me was thinking about how to dimensionalize the skills of developers.  There are a number of very development-centric skills that I have seen that describe what developers are capable of in terms of development.  We could add a bunch of the usual more HR-centric qualities (works and plays well with others, yada, yada), but let’s keep to being development centric.

What then are the 7 Kinds of Developer Wushu?

1. Hackers

I’ll start with the purest expression of development Wushu.  The Hacker grinds out code.  Uber Hackers practically exude it from their pores.  I had the pleasure of working with Rob Barnaby, the creator of the original Wordstar word processor for one gig.  Rob was the consummate hacker.  He could directly type code in as fast as a touch typist could transcribe and in fact, it often seemed like the keyboard was preventing his expression of code from proceeding as fast as his mind could create.  Watching Rob in action convinced me once and for all that an editor had to be fully operable without taking one’s hands from the home keys to facilitate this kind of bond between man and machine at the highest possible bandwidths.

Hacking is distinct from the other forms of Developer Wushu, as we will see.  As an aside, “hacking” used to have a very bad connotation, and maybe it still does in some quarters.  At one time it meant someone who haphazardly coded, beating their way through the process through sheer trial and error brute force.  It was the antithesis of the elegance so many developers worship.  When I use the term “Hacker”, I mean it in a good way!

FWIW, I rate myself a “5″ on the 1 to 10 scale of hacking.  I grind out code pretty well, but if I’m productive, it is more because some of the other Wushus have allowed me to write less code.

2. Language Polyglots

Did you read “Godel, Escher, and Bach?”  Did you really understand what it all meant?  Did you glide through that book effortlessly, constantly in agreement, and finding it a sheer joy?  Or was it one of those books you see that smart people all claim to have read and understood, but that was sheer drudgery for you?  If you’re in the former category, you may be a Language Polyglot.  For you, the ability to execute a language, to be a Turing Machine, is the highest accomplishment of the computer.  It’s what makes it our only Universal Machine, at least until somebody figures out nanotech replicators, which will have to be computers in large part anyway.  My first product, Quattro Pro, contained no less than 18 specialized interpreters that implemented various domain specific languages to accomplish different deeds.  These little interpreters made Quattro Pro easier to write, faster, and more flexible than the competition.  In the end of the day, all things computer wind up being lanuages.  Adobe proved that by making printers into languages in the form of Postscript.

The Language Polyglot makes every problem into a language of some sort.  These folks worship Lisp (first language I learned to program in, yes, I’m a Language Polyglot).  More recently, they create tools like Ruby on Rails.  Ruby, the language, by itself is interesting.  Rails, a framework on its own, is another framework.  But somehow the marriage of the two is magic.  It takes a Language Polyglot to figure out that sort of thing.  Good ones are responsible for all things Meta, which is to say imbuing a software program with the ability to change and take on some of the universal character that makes the computer a unique machine among machines.

I will somewhat egotistically give myself a “10″ as a Language Polyglot.  It’s what I do best.

3. Algorithm Mentats

Ah, the Mentats of Dune.  What a compelling image.

Does your software need to be fast?  Does it need to scale?  If so, you’d better have some Algorithm Mentats.  These people uniquely understand how to combine algorithms and data structures to make a software program fly.  There are lots of sub-specialties.  Database algorithms, parallel and distributed computing, graphics, and others to name a few.

A good Algorithm Mentat is not just good at creating algorithms, these folks are often the most familiar with the literature in their areas of specialization.  Computer Science, as a discipline, is largely about Algorithms and Languages, with some Architecture in the sense I will describe shortly thrown in.

I will charitably rate myself an “8″ as an Algorithm Mentat.  I don’t love it enough to do better, not like I do Languages and UX.

4. UX Wizards

If some poor user actually has to understand and hopefully love your software, your success depends on the quality of your User Experience (UX).  This area is poorly understood, frequently abused, and much talked about.  Everyone is a consumer of UX and everyone therefore considers themselves expert at UX.  Most of them are wrong.  Some view UX as a Design problem.  It’s not really, although Design helps a lot.  Some view it as understanding Workflows, and there are elements of that.  I think about it as a mixed discipline that involves Design, Workflows, Communication, and a deep understanding of what the User is trying to accomplish.

UX is about crafting a medium that communicates in both directions.  Until we had computers, communication was largely one way.  We had writers, composers and musicians, actors, and so forth.  Those folks have a lot in common with UX, but let us not lose sight of the fact that like any medium, UX is specialized.  We don’t expect Mario Puzzo to be a great movie director nor Steven Spielberg to compose a symphony.  They’re masters of a particular medium.  And, it’s a medium that morphs.  Batch had a particular UX, then we had dumb terminals.  PC’s ushered in an era, and then we had GUI.  Today we add Social and Mobile.  What a rich palette for the UX artist to draw from.  It’s all still here, amazingly enough.

I rate myself “9″ on UX.  I hold the patent on spreadsheet notebook tabs (originated in Quattro Pro), and would be named on a patent for the right mouse button if we hadn’t felt it was entirely too obvious to patent back in the day.  We did that first and I remember the Microsoft Product Managers where lined up in the aisles taking notes like crazy when we first demoed Quattro Pro at Comdex.  Pretty soon Excel had these features too, LOL!

5. Architecture Builders

Architecture Builders are masters of arcs and circles.  They know what to put in the boxes and how to connect them for best results.  They think in layers, abstractions, and interfaces.  Refactoring is a joy to be embraced each and every time it is called for.  Patterns are their method of expression, as are the various odd notations associated with Object Modelling.  All large products need Architectural Builders, lest they be poorly architected and collapse under their own weight.  A good Architect can create a product that allows more people to work on it longer, which can be a decided competitive advantage.  Bad architecture results in constant rewriting with the difficulty of finishing increasing almost exponentially with each new release.  Architecture Builders are masters of managing complexity and hiding it where its mischief can be minimized.

I’ve done architectures for software that’s stayed fresh without need of rewrite for many generations, so I’ll call myself a “7″ on this type of Wushu.

6. Process Plotters

What do you call that developer that has a million little scripting tools that make them awesomely productive?  They seldom have to create much as they’re forever transforming or improving using tools and processes.  These are Force Multipliers not to be underestimated.  Whether your Process Plotters are focused on the scripting and tools side or whether they’re focused on Agile Programming or whatever other methodology is the tool of choice.  They know when you have too much process and it is interfering with productivity.  They know when you have too little, and it interferes with quality and ultimately, productivity.  With the right tools, they are the consummate DevOps gurus.  They are consultants and managers who set forth the right campaign to accomplish your goals in a timely way.

While many of the processes and tools of development are useful in other disciplines, there has been little evidence the converse is true.  Assembly lines, Six Sigma Black Belts, and the like have not made much impression on the world of software.  It is for that reason that I call Process Plotting one of the 7 Wushus of Development.

I do okay with process and was practicing a variation of Agile Programming before the movement even had a name.  There are papers written about the productivity and processes used by my Quattro Pro team by a Bell Labs PhD named James Coplien.  They serve as some of the earliest working documents for the Agile movement.  Based on that, I put myself down as a “7″ on process.

7. Black Boxers

This one is a curious trait, but I have seen it in action too many times not to be certain it exists as a powerful skill.   Black Boxers know how to deal with Black Boxes.  They’re the best debuggers, the best at going into code they didn’t write and understanding it.  There are different kinds of Black Boxers.  Some are ideal QA experts.  They formulate tests that are effective in mapping out the unknown territory associated with Black Box testing.  Some are very low-level.  One of my startups involved very sophisticated automated software testing tools.  We had frequent “blue screens of death” as our software had to do a lot of undocumented and unsupported unnatural acts to accomplish its job.  One of our team was an awesome Black Boxer.  He had a hardware debugger, which was a card with a button that could stop the machine and let him poke around inside what was left.  From that, he could usually figure out the source of our BSD and tell us how to fix it.

Incidentally, the very best Black Boxers hack security and break copy protection schemes.

While I have done Black Box reverse engineering, and managed to derive the Lotus 123 file format for Quattro without disassembling any of the software code in 123, I don’t rate myself very high on the Black Boxer scale.  Call it a “4″.

Conclusion

There are at least 7 Kinds of Developer Wushu.  If there are more you can think of, please comment.  It should make for a spirited discussion.  Any developer has strengths and weaknesses along all of these dimensions, though I’ve never met a developer that was a star in every category.  It takes all kinds to round out a team, so it may be helpful for teams to take inventory of the Developer Wushu expertise of their members.  It can shine a light on strengths and weaknesses and inform how you hire and grow the team moving forward.  It may also be helpful when interviewing new developers to think of questions and discussion topics that focus in each of these areas.  Get your developers who excel in a particular art to focus on questions about that art.  You’ll pretty quickly understand what your applicant is capable of and what will be challenging for them.

Those Special Customers Developers Love (Well They Should Love Them!)

Do you have any special customers that your developers hate?

These are the customers that can mysteriously break your products over and over again, even though perhaps thousands of others report no problems.

How does this work?

First, understand the psychology of bugs.  Developers don’t consciously create bugs, they come about as errors of omission, misunderstanding, distraction, and incomplete thinking.  Sometimes they’re a result of interactions between complex connected systems that the Developer does not understand or did not foresee.  Most Developers are pretty conscientious about not wanting customers to see bugs, and about getting them fixed quickly.  At my last startup, the Developers were part of the Customer Service crew, which gave them an even keener sense of the customer’s perspective.  Believe me, they wanted their bugs to stop hurting these customers!  BTW, I use that language of “bugs hurting customers” on purpose, because that’s what it feels like to Developers when they get to experience the customer’s pain firsthand.  I highly recommend it!

Yet, we still have bugs.

Second, consider how it all looks to the customer.  The first thing you have to do before you can put Developers on the phone is to get them to quit taking bugs personally and assuming the customer is wrong.  The customer reports a problem, and the immediate assumption is it is the customer’s fault somehow.  At least that’s how it can feel to your customers.  In reality, the Developer doesn’t literally think of finding fault, but they know the customer is doing something different, something they didn’t think of, and they have to get to the bottom of that as soon as possible.  In the worst case, it feels like a witch hunt to your customers when it shouldn’t.  If customers understood why the questions were being asked and why were they asked in that certain special Developer bone headed way, they would understand more.

Getting back to those special customers, they are the ones that do things differently than the vast majority, for whatever reason.  For example, if I talk to a customer that works in IT, I always take a mental deep breath.  These are the sorts of folks that will customize their browser’s security levels, erect additional firewalls, and do almost anything else to really customize their machines to work the way they want them to.  The vast unwashed are going to run their machines pretty much as they come out of the box.  So, the IT guys see some bugs that the vast unwashed don’t, simply because their configurations are different.

If I’m in a crowd with my wife, trying to find seats, I always follow her.  She’s left-handed and she will make different decisions than the vast unwashed, who are largely right-handed.  We will magically wind up getting to a shorter line or finding the better seats that are still available.  If you know a left-handed person, try following them.  It isn’t just a matter of picking left instead of right.  They perceive all of the cues around them just a little bit differently when making their decisions.

Look for people with different hardware.  They’re travelling the less traveled road.  They will find things your mainstream may not.

I have known dyslexic people who did the most amazing things with software.  I have seen problems uncovered through random behavior.  To a certain extent, I have also seen concentrations of bugs as indicating not just that an area of a product is buggy, but that it has poor User Experience.  Why?  Because areas that have poor User Experience cause people to do all sorts of crazy things as they try to guess at how to work the feature.  Hence it flushes out the bugs.  Always consider UX as a possible source of bugs!  And while you’re tracking these bug concentrations, recognize that unnatural locuses of bugginess are either indicators of Bad UX, Bad Architecture, Bad Developer, or something really really hard that you’d better invest more systematic testing in.  Let’s call these “Areas of Special Interest.”

I unwittingly became one of those “Special Customers” for KISSInsights during the last week (cool service I will have more to say about in a later post).  I had a problem with my account they kept trying to fix and couldn’t.  I escalated all the way to the CEO.  Not only did the problem not get fixed, but problems like making me a premium customer for a month for free were apparently being broken.  Both sides were becoming increasingly frustrated.  Then we discovered the real issue–I had two accounts.  They were fixing the older one and I was viewing the newer one.  DOH!

So what’s the moral?

1. Embrace your special customers.  Reward them.  They are like gold because they’re finding bugs that others haven’t found.

2. Seek out people who experience the world differently when using software.  I don’t know if you can go to the extent of trying to make sure your testers include South Paws and Dyslexics, but OTOH, maybe it’s a good idea.

3. Keep an eye on bug concentrations as a potential early indicator of Bad UX, Bad Architecture, or an Area of Special Interest.

4. Make sure everyone involved recognizes that positives that come of an effective quality process.  Never focus on blame.  Reward progress in discovery, correction, and avoidance.

Scoble Discovers Developers are Schizo About New Platforms

I just listened to Scoble’s bar interview of @longview (Nick Long) and @renatto (Paul Robinett), two Dreamworks developers who are building a mobile app of their own.  They’re talking about the Mobile World, and there are some great sound bites coming from the interview.  BTW, the Cinchcast tool he used to do the interview was pretty cool.

These developers conclude Nokia-Apple are “screwed”, Android is the cutting edge, yada, yada.

Some key passages and ideas I’ve paraphrased: 

-  The constant refrain: “No one is developing apps for X”.

-  It’s costly to learn a new platform.  Android has Java.  If you know Java and have to learn Objective-C that’s hard and vice versa.  You have to hire a new programmer.

-  It’ll be hard for developers to straddle 2 platforms and 3 is impossible.  How can there ever be a #3 of any consequence?

-  You have to pay us up front enough so it wouldn’t matter if anyone bought the platform.  Because they can’t guarantee the distribution.

 - Cool is about openness, not about closed.  The big momentum is with Open on Android. 

-  The Cool Kids want to be on the cutting edge, but that’s slowing down a little bit for Apple.

-  When somebody builds the uber cool app on Android first, that shift away from Apple will be here.

-  Scoble’s advice to Microsoft, get rid of Windows and go XBox.  They may have been too long in the bar at this point!

-  What if the Apple store is full of hundreds of thousands of apps, and you’re lost in that sea of apps.  How about a marketing decision to launch on Google first so you stand out?

Takeaways for Once and Future Platform Kings

I am a developer and have worked with developers for my entire career in a variety of different markets.  I’ve also spent a lot of time doing the “impedance match” between marketing/sales and developers, and formulating winning product strategies in new markets.  Let me tell you it is an interesting challenge to juggle all of those balls just because of how the various players think and are motivated.  It’s worth getting behind the sound bites of this interview and understanding the developer, marketer, and strategic implications for companies who want to be Platform Kings.

Let’s start with the marketing / strategic perspective for the mobile world.  It’s all about the apps you have on phones, and Scoble gets this in a prior blog post very eloquently:

Nothing matters in this world more than apps. Write that on your forehead. Write that on the mirror on your bathroom wall. Write that on your car windshield. Whatever it will take so you remember it.

HP execs know this. Google’s execs know this. Everyone in Silicon Valley knows this.

Apps are the ONLY thing that matters now.

Why? Because when a customer, whether in Cape Town or San Francisco or Tel Aviv walks into a store to buy a smartphone they will NOT want to feel stupid.

What makes you feel stupid when buying a Smartphone? Buying one that doesn’t have the apps your friends are taunting you with.

Apps need a platform, so if you’re going anywhere in these markets, you’d better have one that will attract the right apps.  Unfortunately, it’s getting late to try to establish a new platform.  Why?  Because the developers are in control of whether or not apps will appear on your platform, and you will have a hard time attracting them.  Many companies are woefully unprepared for the idea that if they’re in the platform business, they actually have two sets of customers.  First are the people that buy the phones.  Those are the obvious customers, the ones marketers at companies like Nokia have built their entire professional careers learning how to deal with.  Second are the developers that bring the apps.  These are the customers many of these companies have no earthly idea how to deal with, yet they are the gate keepers for the apps.

So how do we think about developers as customers and how do we get them to adopt our platforms?

There are a very limited number of opportunities to attract developers because they are so schizoid about new platforms.  On the one hand, developers really hate having their expert status reset to beginner while they learn a new platform.  They may protest that its cool, they’re always learning new things, they love to learn, yada, yada, but they really hate the nuts and bolts of the learning.  This is a corollary of what happens when you give a developer somebody else’s code to maintain.  The code may have come from their most revered uber geek hero, but if they don’t know that’s the source, their first words on briefly looking over the code will be, “This code is shit–we have to rewrite it.”  Welcome to the real source of NIH.

So what will get a developer to voluntarily surrender his Uber Geek status for the time it takes to learn a new platform? 

There really are only two things.  Either that platform is so hot and sexy they will lose their Uber Geek status anyway if they don’t learn it, or the platform is so successful that profit motive dictates it must be supported.  Are you beginning to see the problem with introducing a new platform?  It hasn’t been around long enough for profit motive to kick in, so you have to make sure it isn’t just a little bit cool, it has to be ultimately way-over-the-top-super-duper-no-kidding-insanely-friggin-UBER COOL. 

This has been Steve Jobs genius.  He has managed to create such platforms multiple times in his career.  That’s no small accomplishment, and I don’t know whether we’ll ever see it again in our lifetimes from someone else.  The Apple II.  The Macintosh.  The iPod.  The iPhone. The iPad.  Dang Steve, that’s gettin’ jiggy with it.

When the corpocracy wants to roll out a new platform, that’s what they’re faced with.  There are a limited number of things the Corpocracy (my term for that faceless Big Business  thing the lady in the Apple 1984 commercial threw her hammer at) can do about this.  The best one is to make their platform absolutely compatible with some other platform so that developers don’t have a long learning curve.  We’ve seen a lot of those kinds of things going on in the industry.  It’s one reason why some things just won’t die.  Sometimes it works to give away the platform, and make it open.  It’s helpful if in the process you can make it as compatible as possible with something developers know.  Enter Android with a lot of Java inside.

That’s about it.  If you can’t make your platform fit those molds, you’re probably not going to be a Platform King.  Not enough developers will learn your stuff no matter how great it is because it was either not sexy enough or didn’t already have a big enough installed base.  The latter, BTW, is why Gordon Moore says it is better to go from app to platform than vice versa.  At least you’ll have the installed base and ecosystem of the app users to drag developers onto the platform.  They come to make the app users happy if there is enough motivation in that.  But this does not necessarily a huge platform success make.  This is the problem Salesforce struggles with in Force.com. 

Getting back to the Scoble interview, are these developers right, is Nokia screwed?  And whither the other mobile platforms?

Because developers have this big speed bump in their willingness to learn new platforms, they will tend to create sub-cultures that don’t communicate very much.  Right now we have a huge division between the Unix + Open Source world and the Windows + .NET world, for example.  Only a very small number of developers can claim to be Uber in both camps.  The vast majority know very little about the camp they are not Uber in, and often hold it in extreme disdain as a result.  But that does not mean they’re right.  It only means you have to understand where those boundaries are and what they mean to the success or failure of your product strategy. 

Translation:  don’t ask a set of developers about whether a platform they will have to learn will succeed unless all you care about is whether they perceive it as cool.  They don’t know much else.  It’s all religion to them.  Despite the fact they are engineers, very few will look at this sort of thing objectively.

In fact, Microsoft may have the only viable alternative platform opportunity that will work for mobile after Apple and Android.  Why?

Because there is a large community of developers who don’t have to relearn their tools.  To the extent the phone platform can minimize relearning and appeal to that group, they’re in.  It would be ideal if Microsoft can also create the commercial reality of a big enough market.  In fact, that will be a requirement in the long run.  But in the short run, Microsoft needs to stimulate some innovative hit apps on the platform that show life and prime the pump.  Steve Ballmer, if you’re listening, that’s the most valuable thing the billions you spend on R&D could purchase.  Bring 3 to 6 hip, really cool, must have apps to your platform so your customers don’t have to feel stupid (ala Scoble and mobile phone apps) and you have a chance.  While you’re waiting for that lightning to strike, at least make sure you have apps that give great experiences for all the key hip web properties out there, such as Facebook and Twitter.  And with whatever cash you have left, make sure your phone platform is minimizing the speed bump for .NET, Windows, and XBox developers to put apps on your phones.

It’s not too late, but it is far from early.

Related Articles

This community of developers who know Microsoft platforms is one of the under-served markets I alluded to in my article saying that Nokia-Microsoft are filling the last of the 3 winning market strategies.

What Will GPU-On-The-CPU Mean for Analytics?

This week’s InfoBoom-sponsored post is all about Intel’s announcement that it would be shipping chips that include an integrated graphics processor (GPU) on the same chip as the CPU under their so-called Sandybridge architecture.  A lot of folks probably ignored the announcement thinking it meant better video games for their kids and perhaps their laptops, but there is a more interesting way to look at the impact of such architectures for business.

GPU’s are not just for graphics, as it turns out.  They’re extremely powerful supercomputers in their own right, with vector processing and other capabilities that are well on par with the Cray supercomputers that ruled during my college computer science days.  The Cray X-MP ran 941 Megaflops back in the day and was considered strategic weapons grade computing.  The latest Nvidia CUDA GPU’s weigh in at 1 Teraflop or better, so are fully capable of keeping up with the old Cray.  What happens when that kind of power is available on every CPU?  A whole lot of power, and a whole lot of change.

Check out my post over on InfoBoom to find out!

Database.com, nice name, shame about the platform (Huh?)

Matt McAdams writes an interesting guest post for Phil Wainewright’s ZDNet blog, Software as Services.  I knew when I read the snarky title, “Database.com, nice name, shame about the platform,” I had to check it out.

The key issue McAdams seems to have with Database.com (aside from the fact his own company’s vision of PaaS is much different, more in a minute on that) is latency. He contends that if you separate the database from the application layer, you’re facing many more round trips between the application and the database.  Given the long latency of such trips, your application’s performance may degrade until your app “will run at perhaps one tenth the speed (that is, page loads will take ten times longer) than a web app whose code and data are colocated.”  McAdams calls this a non-starter.

If using Database.com or similar database-in-the-cloud services results in a 10x slower app, then McAdams is right, but there are already ample existence proofs that this need not be the case.  There are also some other interesting considerations that may make it not the case for particular database-in-the-cloud services (hereafter DaaS to avoid all that typing!).

Let’s start with the latter.  Salesforce’s offering is, of course, done from their data centers.  From that standpoint, you’re going to pay whatever the datacenter-to-datacenter latency is to access it if your application logic is in some other Cloud, such as Amazon.  That’s a bit of a setback, to be sure.  But what if your DaaS provider is in your Cloud?  I bring this up because some are.  Of course some Clouds, such as Amazon offer DaaS services of various kinds.  In addition, it’s worth looking at whether your DaaS vendor hosts from their own datacenter, or from a publicly accessible Cloud like Amazon.  I know from having talked to ClearDB‘s CEO, Cashton Coleman, that their service is in the Amazon Cloud. 

This is an important issue when you’re buying your application infrastructure as a service rather than having it hosted in your own datacenter.  It also creates a network effect for Clouds, which is something I’ve had on my mind for a long time and written about before as being a tremendous advantage for Cloud market leaders like Amazon.  These network effects will be an increasing issue for PaaS vendors of all kinds, and one that bears looking at if you’re considering a PaaS.  The next time you are contemplating using some web service as infrastructure, no matter what it may be, you need to look into where it’s hosted and consider whether it makes sense to prefer a vendor who is colocated in the same Cloud as your own applications and data.  Consider for example even simple things like getting backups of your data or bulk loading.  When you have a service in the same Cloud, for example like ClearDB, it becomes that much cheaper and easier.

Okay, so latency can be managed by being in the same Cloud.  In this case, Database.com is not in the same Cloud, so what’s next?  Before leaving the latency issue, if I were calling the shots at Salesforce, I’d think about building a very high bandwidth pipe with lower latency into the Amazon Cloud.  This has been done before and is an interesting strategy for maximizing an affinity with a particular vendor.  For example, I wrote some time ago about Joyent’s high speed connection to Facebook.

Getting back to how to deal with latency, why not write apps that don’t need all those round trips?  It helps to put together some kind of round-trip minimization in any event, even to make your own datacenter more efficient.  There are architectures that are specifically predicated on this sort of thing, and I’m a big believer one whose ultimate incarnation I’ve taken to calling “Fat SaaS“.  A pure Fat SaaS application minimizes its dependency on the Cloud and moves as much processing as possible into the client.  Ideally, the Cloud winds up being just a data repository (that’s what Database.com and ClearDB are) along with some real-time messaging capabilities to facilitate cross-client communication.  The technology is available today to build SaaS applications using Fat SaaS.  There are multiple DaaS offerings to serve as the data stores and many of them are capable of serious scalability while they’re at it.  There are certainly messaging services of various kinds available.  And lastly, there is technology available for the client, such as the Adobe AIR ecosystem.  It’s amazing what can be done with such a simple collection of components:  Rich UX, very fast response, and all the advantages of SaaS.  The fast response is courtesy of not being bound to the datastore for each and every transaction since you have capabilities like SQLite.  Once you get used to the idea, it’s quite liberating, in fact. 

Surprisingly, many have seen this model, though they may not have thought much about it.  As McAdams points out, “Database.com will do better with developers of mobile apps, which contain the user interface and the app code in the same bundle.”  Yup, many mobile apps are Fat SaaS.  The architecture becomes a lot more interesting when you start thinking about how popular apps are on mobile versus apps in browsers and why.  This also points the way towards some of the types of apps that are particularly well suited to Fat SaaS:  complex games, rich content creation applications, and a variety of things where the simple fill-in-the-form-and-do-the-workflow metaphor just isn’t right would do well with Fat SaaS.  There are also advantages for cost and scaling, where Fat SaaS it works great so long as your application’s usage patterns are largely hub and spoke.  What I mean by that is that there isn’t a lot of need to do cross-client processing in bulk.  Sure, a record may pass through several user’s clients on its journey, but you don’t have to do complex business logic that involves looking at thousands of those records across many clients very often.  When you’re doing hub-and-spoke, the client hardware is free in Fat SaaS.  It may be cheap in an elastic Cloud, but it’s hard to beat free!

The situation for aggregate processing looks worse for Fat SaaS, but it isn’t necessarily black and white.  Very often we find systems whose transaction processing behavior is a lot different than what we want for Business Intelligence.  Hence we wind up optimizing two different datastores–one the transaction processing store, the other the BI Data Mart.  The same approach can work here.

One last comment about McAdams’ post.  He concludes with a pitch for his company’s products:

The bigger criticism applies to all DaaS offerings, and it’s this: they’re solving the wrong problem. Making databases more accessible to programmers who already know how to use databases is nice and all, but how about making databases more accessible to business users? 

Why not let non-programmers build web apps without writing code? To do this, Database.com would have to include things that Salesforce.com discloses explicitly are not part of the platform: page layout tools, reports, dashboards, and so on. These can be built with Force.com, but using Force.com requires programming knowledge.

It seems to me the more innovative cloud DB players are the companies providing a cloud database with a complete, integrated app development platform that requires no coding, only point-and-click configuration. These platforms, like TrackVia (the author’s company) or Intuit’s QuickBase, are doing more to change how cloud apps get built than the better-known DaaS vendors are.

As I’ve said in previous posts, I’m not a fan of the “anyone can program with our special point and click application” ideas.  The demos look whizzy, but this is really not innovation, and the tools are pretty limited in how far they’ll take you.  We’ve similar tools for a long time under earlier guises such as 4GL or later guises such as the PC desktop databases like dBase or Microsoft Access.  We’ve seen it in languages with UI Builders like Visual Basic or Adobe Flex.  I have to say, we’ve seen a lot more point and click programmers than we have seen DaaS.  In addition, the idea that the problem a DaaS solves is one that is already solved, in other words that they’re trying to make understanding databases easier for programmers who already understand databases is also pretty far off base (and surprisingly given McAdams’ past in DBA software).

DaaS is all about two things that many developers are usually not so good at:  Scaling and Automating Operations.  There is a lot of work required for either and it’s work that the majority of developers who may have a ton of domain expertise for their app area typically are short on.

Forget SaaS vs On-Prem, Here are 8 Application Styles to Consider

The EI discussion about Microsoft’s poor handling of Silverlight brought out the different viewpoints swinging. The “RIA was never a good idea” camp was in full force as was the “this confirms everything about HTML5″ and the “Flash is on the same train as Silverlight” camps.

I don’t see these developments nor the evolution of Flash and its strategy as a confirmation that RIA is a bad idea at all, that Flash, at least is going away, or that HTML5 is the answer to all the world’s problems. Whether your RIA consists of Flash widgets embedded in HTML (my favorite RIA strategy for web apps) or AJAX HTML, RIA’s are essential for many kinds of app and HTML5 is years from being a first class choice for that work. There has been too much tendency to conflate every conceivable nuanced app type as one single web app that is best served by one single technology. That way lies crappy UX, high dev costs, and longer lead times to market.

There are new categories of application coming along all the time, and the vast majority haven’t really stopped to think about the evolution of application types and their ecosystems. Let’s forget the ongoing dogfight about Clouds, elasticity, SaaS, and Multitenant for a minute, and have a look at factoring software along some other dimensions.

I see 8 different application design centers, and you choice of which design center to use and which tools and platforms to go with it can matter quite a lot.

#1 Plain Old Desktop (POD) Apps

 

I always loved the term “POTS” = Plain Old Telephone Service, so I’ll borrow the idea for PODs, which are “plain old desktop” apps. This is still a huge business including MS Office and much of what Adobe sells by way of content creation tools. It’s also huge for complex games, though the platform is sufficiently separate we will want a separate category for console games which I won’t get into here.

Typical platforms include the desktop OS–Windows or Mac, and the traditional developer languages such as C# and Java. To deal with the pains of PODs, your app needs to be something that requires too much horsepower for the other architectures as well as a rich User Experience (UX).

#2 Server Software

A command line is a UX, and for some purposes, its even a good UX, so we will count this as an “app” category. It’s like the PODS except there are more languages and OS’s to consider. On the OS side we have Unix in commanding lead (in all of its many flavors) with Windows distantly to the rear. From the langauge side, the world has probably spent more time and effort building an explosion of different evolutionary language branches here than anywhere else. I can’t even begin to list them all, but suffice it to say that when in doubt, you could do a lot worse than to bet on it being a language for server side development. Certainly we can count on Java, C#, and Ruby on Rails as all being in this category.

Some languages are a little bit muddled as to whether they’re server or client languages. PHP is a little of both that mostly errs towards client in my book, but you wouldn’t think of it for server-less apps (if no client is a headless app, are those tail-less apps?). For this app category, we have no UX but a command line, so I’m not sure we’d pick PHP. Put it in the category of helping out Plain old web apps and RIA’s.

#3 Client Server

 

The Client Server model is tried and true and still a huge business, especially for business software. I don’t know how much genuinely new Client Server software is being built anymore. The Cloud and SaaS are a much better model for most applications. Think of Client Server as the somewhat unwieldy combination of a POD and Server Software. Most of what I’ve said for those other styles carries to this one when combined appropriately.

The combination of Desktop, Server, and Client Server are the oldest app styles that are still vigorous today. We’ll call mainframe software a flavor of Server or Client Server. All three are under siege or revolution. Desktop and Client Server are clearly under siege as various web technologies via to take their place. Server is under the dual revolutions of Cloud and Multitenant SaaS. There have been many minor infrastructure revolutions as well as the world transitions from SOAP to REST or decides POJOs (Plain Old Java Objects) make more sense than deep J2EE architectures (let alone CORBA style, Service Bus, and all the rest of that melee).

#4 Plain Old Web (POW) Apps

 

No fancy RIA tech, AJAX or otherwise. This is the modern equivalent of the half duplex 3270 green screen. But, it is lowest common denominator friendly. That means everyone can access it, but the experience may not be great. Save it for times when coverage is more important than satisfaction. Simple UI you just have to get through once in a blue moon is perfect.

The platforms? Who cares. POW apps should use such vanilla HTML they never notice. Tools and languages? Vanilla HTML and whatever your favorite dev tools are for that.

If we add POW apps to the other 3, you really do have the majority of revenue and installed base at present. What follows are newer models that are catching on to a greater or lesser degree. I should add that I see POW as stable and non-controversial, Server as growing but full of revolution, and the other two (Desktop and Client Server) as in decline to greater or lesser degrees.

#5 Rich Internet Apps

RIA’s are web apps that live in the browser but provide a nicer UX than a POW can offer. AJAX, Flash, or Silverlight have to be there for it to count. HTML5 supports this poorly at present, but everyone knows it wants to go here over time.

The “Rich” part of a RIA can boil down to lots of things, so let’s call some out so they don’t go unnoticed. Yes, we will started with Rich User Experience. But what does that mean?

Well, instead of posting a form, you have enough expressiveness that you can actually create new kinds of widgets and respond to user inputs with much more fluidity. We also have rich media, including sound and video to play with, as well as sophisticated ways of manipulating bitmaps to produce animations and art.

However, depending on the RIA platform, you may also experience other “riches.” Flash player delivers a very high performance virtual machine. It isn’t Java-class, but it is darned good. Recently, browser makers have decided performance matters for HTML as well, but it isn’t clear they’re keeping up with Flash. If your RIA has to do some kind of crunching, Flash may help it along. It isn’t just about the high performance VM, there is also the support for more elaborate data structures, which are also helpful where more horsepower is needed.

I have been fascinated by an idea I came up with called “Fat SaaS”.  We live in the multicore era where computers no longer get faster in raw terms, they just get more cores.  At the same time, it is very hard to write software that takes advantage of all those cores.  On the server side, the world has been evolving towards dealing with the issues need to scale large problems onto grids of commodity PC’s as a way to deal with the realities and economics of the multicore era.  On the client side, it seems that machines accrue more and more unused capacity without delivering good reasons for customers to upgrade as often as they used to.

Fat SaaS is an architecture that pushes as much down onto the client as possible and leaves the server farm largely for data storage.  In an extreme Fat SaaS case one could imagine that the clients become the business logic processing grid.  The goal is to tap into the computing resources that lie fallow there, and there are a lot of them.  Most organizations will have more client cores than server cores.

But we digress…

The last bit of “riches” I want to touch on is device independence.  We largely got there for server software, and write once run anywhere is a beautiful thing.  Other than Flash, we are nowhere in sight of it for the client.  This is a sad and embarrassing tale for our industry, and one that developers too often try to power their way through by just writing more code.  Browser incompatibilities are insidious.  As I write this article in WordPress, I’m trying to use their rich text editor.  It runs with varying degrees of success and a little differently on each browser.  Lately, it mostly fails on IE, meaning the UX has not been kept up to snuff.  If they would simply invoke Flash to do one single thing, manage the text editing, they could deliver an identical experience on every browser, not to mention many mobile devices too, though on Apple’s devices they would need an app to do that.

This browser dependence is absolutely the bane of HTML based RIA’s, and I can see no reason why the problems won’t continue with HTML5.  As vendors race to see who can deliver better HTML5 support sooner, keep eyes peeled for the incompatibilities to start.  If they do, that’s a sign that the HTML5 dream is not all its cracked up to be, even in the fullness of time.  It will take some new generation and a bunch of restarted browser implementations to get there.  Meanwhile, Flash will have gained another 5 to 10 years lease on life, despite detractors.

#6 Rich Internet Desktop Apps

RIDs!  A RID is a really cool thing.  It is the web era approach to building desktop apps–we build them with web technology.  Amazingly, nobody seems to have noticed that if you need to run disconnected, or if you want to build an app with web technology that does meaningful things on the desktop, Adobe is the last man standing.

Google killed Gears and Silverlight looks more and more deprecated by the day.  HTML5 is still struggling to get to the minimum RIA bar and will be for years.  What’s a poor RID developer to do, but focus on Flash?

RIDs are fascinating apps, and I would argue your nuts to build any new PODs or Client Server when this model would work. In the area of games, there are amazing developments in 3D coming for Flash Player that will also play to this architecture. Lastly, Ialready mentioned “Fat SaaS”, a model which is ideally suited to RIDs.  The RID just gives the Fat SaaS access to local disk and more of the machine’s facilities.  Fat SaaS work can go on whether the client is connected or not, and a connection can wait until the client needs to connect, which reduces the demand on the Cloud Server Farm still further.

#7 Mobile Apps

MAs are closely related to RID’s, and certainly much better known. The non-HTML RIA platforms are excellent for this purpose, and it is no accident MSFT sees this as Silverlight’s future.  HTML5 doesn’t do enough and it will be years before it does to have real apps stand alone with it. iPhone’s default toolset is basically foisting desktop technology on you to build these apps, and I’m skeptical this is as productive, but the stakes are high enough people deal with it.

#8 Mobile Internet Apps

MIAs:  when you want to live in a browser on a mobile device.  Plenty of data suggests that for apps that are not heavily used, users prefer to consume via browser.  This shouldn’t be controversial as it simply makes sense.  The browser makes it much easier to dip in and out of a lot of apps that you probably never use enough to learn really deeply.  MIAs are a different category than RIAs because like the RIA, there are considerations beyond one-size-fits-all HTML.  However, a MIA could be a RIA MIA (LOL) or a simple HTML MIA.  I won’t bother breaking those two out as new app types–we already have 8 and that’s enough.  The reality is the MIA is a placeholder reminder that you have to do something to make your app palatable on a mobile device lest you have a below par UX.

Conclusion

Have you thought about when to use each of these design centers, what the optimal tool sets are for each, and especially how to weave an all-platform strategy with as little work as possible?

Most haven’t.  I see low expertise in out in the world as much of this is new and very few organizations have so much breadth of experience.  Most of the time organizations start with one design center and move chaotically on to others as targets of opportunity present themselves.

We increasingly live in a world where being on one or a few platforms will not be good enough, and we won’t be able to build for all with organically grown “luck” strategies.  Maybe this is a good time to start thinking through these issues in a systematic way for your organization and its products?

Related Articles

Recursivity and RWWeb talking about Fat SaaS.

Is Twitter Not Multitenant or What?

So here I am, 5 days after the big announcement, and still no new Twitter UI.  We just finished a weekend, which would seem to me like a logical time to roll it out to the remainder of the audience.  No joy.  WTF, over?

Is Twitter not multitenant, or what?  I sure they look with disdain at hearing that term usually reserved for business SaaS software, but I mean really, what’s up with this, guys?  Did you not get the memo about keeping all users on the same code line?  Did we forget to Tweet that somewhere along the line so you never read it?  Is your architecture so fragile that you can’t afford to let everyone have the new UI at once?  WTF is up with this?

I don’t know what’s up with me on this.  I mean, some guys who “get it” are all “Meh” about it, while others think it’s a whole friggin’ platform.  Basically, Twitter needs to be a richer medium for me to like it better, so it sounds cool to me and I want to see it. .

OK, I can see the advisability of not rolling it out to everyone in one fell swoop.  I’m trying to calm down, and sure, I’ve written about release feathering myself.  That’s kewl and all, but how long is this going to take and why isn’t there more transparency into when I as a user can expect to get the UI?  You know, like there must be an algorithm or some such.  If my handle starts with an “A” I get to go first, unless I’m a Tech Crunch reporter with the handle “Zelda” in which case I get to go first too.  Hey, at least I could figure out what to expect.  Or maybe you could even make my expected upgrade date accessible to me in the UI somewhere.

Here is the thing.  If you are going to make the biggest update ever.  If you’re going to have PR about it and all.  You’ve got to have more transparency and a shorter release feathering cycle so people know what to expect and can get access sooner.  I mean Google is much bigger and managed to get the Priority Inbox to me a lot sooner.  After all, you’re pissing off guys like Anil giving it to his wife before him and all.  Anil is right by the way in that post about it being a platform that doesn’t act like Switzerland (if you want to call that pane a platform).  But Twitter has been acting more and more walled garden-ish all the time.

Do you know what I mean?

Android is so Open, it got Flash Back on the iPhone

How ironic.  On the same day that MG Seigler was penning one of his characteristically snarky posts (snark is one of the ways Techcrunch pursues its Follower Economy) about how Android isn’t really open, Apple announces the return of Flash to the iWorld.

Adobe’s stock price is cooking this morning as a result (I wonder if 10% of Adobe’s revenue is even traceable to Mobile Flash? Maybe), and I have to admit, being the Adobe Flex fanboy that I am, I’m chortling over my morning cafe mocha too!

A couple of things to talk about on this news.

First, why do I award credit for this to Android?  Peeps, come on–Steve Jobs didn’t just wake up from his hissy fit about Flash (thanks for that link, Larry!) and decide, “Oh darn, I was wrong.”  No, no, no, not happening.  Something grabbed Steve Jobs by the throat and shook him right out of his reality distortion field.  That something was competition.  Not only has Android been selling extremely well, but the Bastiches have even been using Apple’s, “Hey, we’re not the Man, we’re Cool“, marketing tactics.  Dude, what’s next, Android thinking differently (I can’t see Google having the populist moxie to get that grammar wrong the way Apple did, all those PhD nerds just couldn’t handle it).

Competition is what forced this change, MG Seigler.  Android’s “We’re more open than open can be” pitch was working.  In fact, this Apple announcement sweeps away most of what one would’ve argued were barriers to openness.  It isn’t just Flash that benefits.  Besides which, a heck of a lot of people love their iDevices (3 out of 4 of our whole family have iPhones and we share an iPad) but want Flash access.  Forget movies, they can change.  I can’t even see the stock graphs on Yahoo because they’re Flash.

Gordon Gecko was wrong when he said, “Greed is good.”  It pains me as a person often described as being slightly to the right of Attila the Hun to reach that realization.  What Gordon should have said was this:

Competition, for lack of a better word, is good. Competition is right, Competition works. Competition clarifies, cuts through, and captures the essence of the evolutionary spirit. Competition, in all of its forms; Competition for life, for money, for love, knowledge has marked the upward surge of mankind.

And here, it has let Flash back into the iWorld.  Good job, Android!

Second, I want to take a few lines to talk about why I think Flash is so important.  Much has been made of how the LAMP stack has transformed web development.  Companies can now create products without requiring millions of dollars in R&D expense.  But the LAMP stack primarily benefit the back-end, in other words the server-side.  What about the client?  What is the equivalent of a LAMP stack for client development?  Unless you’re a tremendous fan of 3270 green screen UI, and I know some are even in this day and age, you need the equivalent of the LAMP stack to efficiently product great clients.  Here is the secret:  Flash is the LAMP stack of UI development!  Yes, there are some Flash wannabes out there, specifically Silverlight.  So what?  Microsoft would love for .NET to be the LAMP alternative too.  Flash is it for these simple reasons:

-  It is ubiquitious.  Aside from the iWorld, and that changes today, the vast majority of the world has already installed Flash and it runs in their browsers.  That’s 99.3% penetration in mature markets.  Essentially, everyone has it.

-  It is a write once run anywhere tool that really works.  You write your Flash code and all 99.3% of users can run it without you needing to give it another thought. 

-  AJAX and Javascript, the alternative, is riddled with browser dependencies.  Any dev team that has tried to get even simple rich UI like a Wiki-style rich text editor to work understands this.  It’s a huge overhead to keep up with all of these browser dependencies, and a constantly moving target.  With Flash, Adobe does that work for you so you can get on with building your app.

-  Flash has amazing graphical power and Job’s protestations to the contrary is actually quite fast.  People are writing 3D games in it, for example.

-  Flash can transcend the browser to create apps via AIR, and as we’ve discovered in the mobile world, apps are where it’s at.  Google used to offer Gears for this purpose, but pulled the plug on it.  Silverlight?  Hey, competition is good, bring it.  But they aren’t really there yet.

This all adds up to something that’s very important to the ongoing evolution of User Experience across all devices.  Simply put, Flash deserves to keep going and to be available on all those devices.  Thank you, Steve Jobs, for relenting, even if it took a gun to your head.  Adobe: now is not the time to rest on your Laurels.  There are some issues here and there in the House of Flash that you still need to attend to.