Sometimes there is No Perfect Choice…

>>>Sometimes there is No Perfect Choice…

Sometimes there is no perfect choiceThis past weekend, an online venture called Glitch shut its doors. It was the dream project of Stewart Butterfeld, the founder of flickr.com (which sold to Yahoo in 2005 for $35 million). The site was a “Massively Multiplayer Online Role-Playing Game” — MMORPG to those in the know – which simply meant that people all over the world could simultaneously play the game, interacting with each other and with the virtual world in real time. The front end of the game was written in Flash, but had no mobile or tablet client. Despite some ground-breaking work in concept, execution and technical acumen, it shut down due to an inability to financially maintain the game. Development and maintenance costs balanced against revenue from users not only wasn’t enough to support the company, but the owners even admitted that they had done the future math and found that the delivery model itself was financially unsustainable even if they achieved the use and subscription rates that they had wanted. You can read their sign-off, which is unusually candid for a startup that just burned through tens of millions of dollars, here if you’re interested.

How does this apply to the Enterprise? Well, one of the reasons cited for the lack of uptake of the game and for the bad cost-per-user slope was the choice of Adobe’s Flash to deliver the content to the end user. Obviously, the platform that we choose can have an enormous impact not only on our software’s adoption rates, but also on how sustainable it could be in the future. As we like to say in Application Development, the devil truly is in the details, and when you are pushing the boundaries of the current technology like we do at SDLC, sometimes those details do not become apparent until after you have made those choices. When you say, “let’s see how far we can push things until they break,” at some point you have to expect them to… break. Now, good testing and prototypes can help to mitigate the risks inherent in such a thing, but in the environment of the rapid proposal cycle we all know and love, you cannot crush every last piece of risk, especially out on the bleeding edge. Sometimes, and I’ll throw out this quote since this is a geek-heavy piece anyway, you gotta roll the hard six.

So, could Glitch’s architects at Tiny Speck have reached a different outcome with a different front-end technology? If the goal was to provide a true web-based experience, the current drum beat is HTML5! HTML5! HTML5! However, if you do some digging from people in the know – developers who are pushing the boundaries like we are – you will actually hear more about the promise of HTML5 than the realization of it. There are still a lot of gaps, and we are hitting them daily in our work. While Rovio had mild success recoding Angry Birds in HTML5 for Google, by all accounts it was a hack-fest, with a large portion of the effort spent working around the limitations of the technology. That is, of course, how you innovate and learn. But it’s not the place for the Enterprise to play.

As we push out to the web and look for a unified architecture on which we can deliver the rich user experiences that our customers increasingly demand, what are we to do? I’m convinced that right now there is no best answer. Cases like Glitch/Tiny Speck show that you simply cannot stick with Flash or any other proprietary technology. You cut yourself off from an enormous portion of the market. SDLC made that decision last year, and so far has not regretted it. But HTML5 is not the answer yet. In addition to the technical gaps, there are some business problems as well. Looking back to the Flash client of Glitch, even if it could have been written in HTML5 and achieved good performance (which I don’t think it could have), there would be business indications against it. A proprietary system like Flash provides your company with a secure sandbox. You can push your data, assets, and even code to the client and know that while the client can use them, they cannot get at those assets directly. Do our customers really want their secret sauce open for the world to see? Are the algorithms, assets, and data that they’ve spent years and millions of dollars collecting and developing just there for the taking on a free Internet connection on an open computer in a library somewhere? Right now, if you build something in HTML5 and JavaScript there is nothing to prevent a savvy user from essentially making a local duplicate of everything you are sending them, picking it apart and re-creating it for themselves. In the Enterprise, that is unacceptable.

The prize in this new era of the web platform will go to the company that can figure out a way to deliver and run what is essentially un-compiled code securely on the user’s side. The future of the web will be built on HTML5 and JavaScript, but how the Enterprise will participate turns on this technological fulcrum. What would that look like? Perhaps signed packaging of JavaScript built into the major browsers that run in an opaque execution space? That is essentially what mobile platforms are doing. Whatever the solution, until it shows up, there is no right choice.

So farewell Glitch and Tiny Speck. Thanks for the good times and for the innovations, insights and lessons — both positive and negative — in the wild world of browser-based client-server experience delivery.

Roland Hess is a Senior Consultant at SDLC Partners, a leading provider of business and technology solutions. Please feel free to contact Roland at rhess@sdlcpartners.com with any questions on this blog post or to further discuss web development.