Why Mobile Apps Are Obsolete

Everywhere in the software development world today you hear about mobile apps.  iPhone, iPad, Android, Symbian, even old J2ME.  More and more on-handset applications available, 100,000, 250,000, growing and growing, from GrandTheftTrademark LXXVIII to 2 Gerbils, 1 Cup.  It's almost as if the mobile web has ceased to exist, after all, WML is all but dead, and with the customizations needed to get XHTML to display properly on all devices you might as well be writing a custom app for each one.

But don't be deceived.  Mobile apps are dead.

We've seen this story before.  Desktop apps were all the rage once.  Instead of connecting to a mainframe and getting your thin slice of time, or even worse waiting for your batch job to get scheduled, you could run on your own machine at your own speed.  Freedom.  And yet, day by day desktop apps are being replicated on the web.  Sometimes better than what was there before.  Increasingly they are replacing desktop apps altogether.  Personally, I've seen the desktop apps I use fall one by one as more and more migrate to, or are subsumed by, web apps.

Mobile is following the same trend and in the Kurzweil Accelerando sense, this will all happen much faster than it did with desktops.

The reasons are many but the concept is simple: programmer motivation.  Anyone who has written mobile apps knows what a pain in the ass it is.  Not only do we often have to deal with out-of-date paradigms - Objective-C, J2ME - we get stuck in the need to customize the app for virtually every handset to provide a good user experience.  The whole process is obese with process and, most importantly, it isn't fun.  Testing and debugging also present special problems.  And don't even get me started about the installed base, compatible versions, migration.  You end up spending most of your time getting the app to work right on the Samsung Hentai-XXX1007i that the executive who approved the project has, instead of making cool new stuff.  It's a situation worse, far worse, than when we just had to provide Windows, Mac, and sometimes Unix apps.

Enter the mobile web app.  iPhone was the breakthrough for mobile apps, true, but just as much it was the breakthrough for the mobile web.  It was the first real browser that could run many web sites, in fact one of the reasons I purchased it when it first came out was it was the only phone that could access my secured network monitoring web app.  Now just about every new phone coming out has a decent browser.  And not just the old limited mobile browser, but ones that can carry their weight in javascript, css, and with decent speed.  With HTML5 with Canvas, with WebGL, with WebSockets, there's a huge amount you can do you could never do before on the web.  Personally I've been switching several apps I used to use on the iPhone and iPad to their mobile versions, because they are faster, updated constantly, less crash prone, and more featureful.  It's getting better all the time - and at an accelerating rate.

Mobile browsers are approaching parity with their desktop cousins.  The same can be said with processing power, memory, storage, bandwidth, screen resolution.  Soon there won't be any need to create separate mobile versions of your app, or any separate versions at all.  Write once, run anywhere will finally have arrived.  And better than it was envisioned - you won't have to install anything, download anything, worry about spyware crap, local diskspace.  The mirror image of the Cloud is an unhooked User.

Write Once, Go Everywhere.

Now get out and start hacking the mobile future!

Why using REST will kill your project

REST is fun, but as with most things that are fun, it can also kill you.  First off, if you don't know what it is, and don't be ashamed because I missed the boat for several years after it came out, go to the wikipedia entry.  It seemed like a cool idea and I've designed several APIs in the REST paradigm.  However there is a dark side to REST, which can be deadly, and can kill, and in many cases has killed, projects big and small.  I'm going to use real examples here, but without the names of the companies or participants to protect the guilty.

Let's look at the two major paths software projects start down these days and where REST fits in.  We've got waterfall where you go and design your high-level architecture and APIs and components and let's say you decide on REST.  So you've got a big list of APIs with annotations and in the case of REST these are actual URLs you could call along with the JSON or XML data structures.  On the other hand if you're agile you're going to start out with a minimal set of REST APIs in the first iteration and then add more as you go on until you eventually get to the same place of a bunch of REST APIs with their JSON or XML backing.


To implement this you're going to have an app server jboss/django/rails/etc with code in Java, python, PHP, Ruby, whatever, some Apache, a proxy, a local MySQL/Postgres/Oracle/whatever DB, maybe a Cloud DB thrown in their, maybe your whole thing is running in the cloud.  It doesn't really matter for the purposes of this discussion, what matters is the resulting architecture driven by REST.  Here's an example diagram approximating an actual large-scale system I've worked on:

Everything looks nice and standard and "best practices" buzzword compliant future-proof, doesn't it?  Well in an enterprise system it's actually quite a bit more complicated, such as additional load balancers and rewrite engines and gateways and proxies and components, but this is the gist of it.  The important points to note are the multiple REST components and prevalence of proxies, because this is what will end up leading to our demise.

You see the root of the problem, I believe, is that REST is a heavyweight protocol.  At first when you are designing the APIs in waterfall you try to alleviate this by chunking requests, and having fat methods that return lots of data in one go.  In agile you don't notice it at first but when you start to scale you notice how slow everything is and how your traditional optimization strategies don't seem to work so well.  Basing an application on REST is like basing an assembly program on interrupts, as the early Macintosh I/O was, like putting every memory access over a relatively glacially paced network bus.  The simple act of an HTTP request/response, especially for anything complicated, is quite slow compared to on-box requests.  When you start multiplying components, and have REST requests which to complete must call other REST requests in a cascading tree, then the problem becomes quite troublesome.

There are standard approaches to remedy this situation, all of them ineffective in the long run.  You can try to add more boxes, virtualized or no, cloud or not, with smart load balancing.  Unfortunately this just reduces load but is not going to speedup your shortest path.  We don't even need to invoke Amdahl's Law here, but even if we did we still have enough non-parallelizable operations in enterprise software to complete a REST request that just adding components won't fix everything.  So we also try adding proxies, so we can cache requests, after all the best request is the one that is never made but just taken from an in-memory cache.  Sounds nice but soon you find this adds a whole new level of complexity to the system as you have lots of state-sensitive calls, such as authentication, authorization, purchasing, downloads, transactions, where you need to not cache the responses.  However just not caching these with no-cache denies you most of the benefit of using the proxy so you then have to design added complexity to figure out when you can rely on the cached copy and when you cannot.  So now it's another component, more synchronization, more complexity, more subtle bugs, and more slow-downs.  Then you find that the very approach you thought would save you becomes your downfall.

The core problem is architectural: using a high-latency high-overhead interface in internal APIs.  This is where REST fails and is doomed to fail by its very nature.  Complexity kills.  KISS: Keep It Simple, Stupid.

This is not to say that REST has no place in software design.  As an external-facing API it can be an excellent solution, especially in reducing the monstrosity that was SOAP and WSDL.  It is here that REST demonstrates its greatest strength of providing an intuitive, simple and easy way to access resources and perform operations over the web.

But keep REST away from your internal architecture, as it will in the end impale your beautiful design on the pike of reality.

Liu Xiaobo wins Nobel Peace Prize

China is still stuck in the dark age of human freedom.  Fortunately, some Chinese are waking up and trying to make a difference:

Liu Xiaobo wins Nobel Peace Prize

Bravo to the brave path of all those involved in Charter 08.  The Chinese government seems to think it can continue to advance technologically and economically while following Oriental Despotism.  Aristotle warned of its dangers and many in China are waking up to its evils as well.

The Chinese cannot continue to send their best and brightest overseas to escape tyranny and oppression.  Sooner or later, and let's hope sooner, they will need to stop blocking Facebook, shut down their Great Firewall, and join the rest of the civilized world.

Anti-Rant: Berkeley Bionics eLEGS

This site will take a brief respite from ranting to anti-rant about the Berkeley Bionics eLEGS Demonstration.  This is one of the best new technologies I've seen in a long time: restoring walking ability to paraplegics.  Not just a pie-in-the-sky demonstrator, an actual technology, with actual paraplegics walking.  Amazing.

Having had an uncle who was paraplegic, and also a technology μManiac, I know if he was alive today he would be as excited about this as I am.  A startup making a real difference in the world, for the better.  Bravo.

Read more at http://berkeleybionics.com/.

Why I Don't Give a Rat's Ass About Open Source

Lots of programmers think open source is a good thing and the future of software.  I think they're full of shit.


All the best and latest software is proprietary.  What might we consider to be the most advanced software running around the globe?  The Google File System, Google Maps, Google Search, BigTable, Facebook, Twitter, the iPhone, iPad, vxWorks RTOS, these systems are all 100% proprietary.  Sure, they may use some open source when it suits them, like Google with Linux or Facebook with Hadoop, but their core systems are all proprietary.  Google has no intention of releasing its search code as open source, ever.  Nor Facebook or Twitter their web frontend and backend code.  And we know how Apple feels not just about open sourcing their OS but even letting you run your own unapproved applications on your Apple i* hardware.

There are very few exceptions, and they tend to be confined to problems that were solved decades ago, like unix operating systems such as Linux, text editors such as Emacs or VIM, IDEs such as Eclipse, programming languages almost two decades old like Java or python, solved problems like web servers with Apache.  Anything involving mature technology that doesn't provide enough value to pay for proprietary code, is about all you see of value in open source.


Now you're going to tell me about Hadoop, and all I'm going to say is the volume of data going through it is a fraction of what you'll see at Google.  It's a way to setup a system when you don't have the money of Google to do it right and don't mind half-assed performance.  Is that why facebook and twitter are so fucking slow all the time?

At one point in the past, I cared very much about whether software was open, not just open but free in the GPL sense.  It's not Linux, it's GNU/Linux, and all that.  But over time I found that what I really wanted from software is the same thing that the average user wants.  They want something that works, something that's easy and fast and performs a useful task.  Whether the source code for that is available or not is at best irrelevant, and at worst a harmful distraction.  The obsession with licensing is similar to the obsession with architecture and design, both are a dumb waste of time.

Or as the great Charles Myron Lowell put it:

"Programming Myth #1: Users Care About Elegance."

I don't care, and neither should you.

Real Programmers Don't Do Conferences

Real programmers, that bombastic breed of half-commando, half-superhero, half-パラサイトシングル midnight gangster with the virtual girlfriend and real-life it's-complicated sex partner. You know who you are. Down in the trenches, in the server room, in a windowless office at 3am barreling through the third batch of espresso made with Water Joe debugging a 450,000 line monstrosity that mankind has no business investigating. You with the sunken eyes, the perpetual off-in-the-distance stare, the kind of look that makes you know a conversation is only ever half-listened to. The face that says, I'm thinking of something else more important right now and the Real World is bothering me with its compromises and opaqueness and lack of su privileges.

You know these types, these Bamboccioni, if you know anything about programming. You may have been one. You may even be one. But we all can appreciate who they are. At the end of the day, they're the ones that actually make our computers do something useful.

I can tell you one place you won't see these people. At an IT convention. Sure, they may drift around Black Hat once every leap year, or they may tag along as a sacrificial lamb for some marketing department drone who's too busy practicing his O-Face to learn how to demo Great Incredible Enterprise Collaboration Tool 2.0. But they don't make up much of a convention and they sure as hell don't have the social skills to stand up in front of a group of people without puking and later going Columbine from the aftershock. They fear crowds, know others primarily by their IRC handles, and generally despise other members of the human race.

Now I know what you're going to say. What about Linus? Gosling? RMS? insert your favorite tech god here. I don't dispute that they may have once been Real Programmers, perhaps they were. But they aren't now. Now, they are prophets. Too busy teaching and preaching to listen to the winds in the wilderness. Once cannot be both a contemplative monk and a rock-jock conference deity pulling down $3m a year, plus endorsements. The Church has its Regular and its Secular, and spouting off at IT conferences is most definitely in the Secular camp. Sorry brother, but you've traded your desert-worn camel skins for the finest silks of the Vatican.

Next you'll retort, wait a minute pal, I'm not some conference VIP, I'm a Real Programmer and I go to conferences all the time to network, to meet other coders, to ride the bleeding edge. Yes, you may program, I don't deny that. But you're not a Real Programmer. You're networking? Real Programmers do that online, faster, better, and cheaper than you could ever do bringing people to one physical location. You want to meet other coders? Real Programmers don't meet people, they meet programs, they meet source code, they meet chat windows that may or may not be friends or federal agents. You want to ride the bleeding edge? In the time it's taken you to sign up for a nametag, you've already been passed up by the blokes coding at that very instant.

So who's going to conferences, if not Real Programmers? I'll tell you who. Salesmen. People with something to sell. Maybe they're selling their brand, like a marketing agent. Maybe they're selling their product, and trying to get you to sign on the bottom line. Maybe they're selling their framework, their methodology, their startup. Maybe they're selling consulting time. Maybe they're selling their waking hours, trying to find a better job. Maybe they just want an employer-sponsored trip to Vegas. I don't know. But what I do know is, they're not programming, at least not spending the bulk of their time programming. That's being done by the guy without the expense budget.

So enjoy your cocktail shrimp, your hotel mints and model-presented game preview. Nothing wrong with that, it takes all kinds to make the world go round. But don't pretend you're a Real Programmer.