JP Rangaswami reflects on a recent talk by Alan Kay here. Things get interesting when Kay wonders aloud
He asked something very simple: How come there isn’t a Moore’s Law for software? That felt good, just writing it. So I’ll repeat it. How come there isn’t a Moore’s Law for software? The way Alan asked it, there was an underlying innuendo. That we were wrong about many things we’ve done in the past thirty years, in terms of networks, operating systems, programming languages, hardware, applications, the lot. That the way we built them was wrong, and that we continue to compound the error.
Indeed, that's a great question. Why isn't there a Moore's Law for software? What would it mean to have one?
The classic Moore's Law is pretty simple in concept, and has proven amazingly durable ... namely, that transistor count for a cheap device would double every 24 months. Variations of this for aggregate computing power, storage, and a few other related areas have proven out as well.
Why Doesn't This Apply to Software?
The original Moore's Law (in all it's forms) really applies to individual "computing elements". So as long as an application is willing to live within an individual system the software will scale with that element.
But that almost never happens, as we all well know. Why not?
First of all, developers love to use increased power to add functionality. Well sometimes for functionality, but probably 90% of the time for thick layers of eye-candy. Why do that? Pretty easy, really - customers like it. When customers like the eye-candy, they buy more software. When customers buy more software, developers and their shareholders are happier. Makes sense!
This tendency in and of itself is pervasive enough that is a very large factor. Probably the simplest example is creating a document. In the late 70s you might create a plain text file on a green screen, and if you wanted to get fancy you'd throw some formatting commands into it and *bam* you were done. That same task today might take three or four orders of magnitude greater computing power to do the same thing. Easier? Probably. Flashier and more functional? Undoubtedly. Heavier and far more demanding? Absolutely.
Even the actual, unadorned functionality additions blur the point. How much functionality has been added? When have you "doubled" functionality? What does that even mean?
Which brings us to the second point - "software capacity" is very difficult to define, almost impossible, really. Many people have tried, many people will continue to try. All of that effort is fine, but mostly besides the point. Even if we can't analytically measure "software capacity" we know there's a problem.
The Problem
The problem shows up in a million different ways - unhappy customers, inability to grow your business, customers being dropped from websites, transactions lost ... never to be found again.
Back to JP Rangasami's thoughts on Alan Kay's challenge:
I’m particularly taken with his challenge on scale, his accusation that we don’t design things that really scale.
With processing power, storage, and even many forms of communications bandwidth marching relentlessly into new frontiers of capacity, why can't software scale?
Simple - scaling the old-fashioned way is just hard.
The Old-Fashioned Way
The old-fashioned way is really just brute force, at least from the app developer's perspective. Take care of your own scale. Plan for and deal with failure everywhere. Steep yourself in messages, threads, state mechanisms, and complex distributed architectures everywhere.
Mull over the failure conditions. What haven't you thought of? What could go wrong? Patch here, patch there. Worry about race conditions, deadlocks, and just weird behavior.
Then put it into production and carry a pager.
Irony
There's a real irony, a classic conundrum here - the exact stuff that you're going to do to enable scale, to make use of all of that Moore's-Law-hardware is precisely where your problems are most like to occur.
You simply know the raw capacity is there ... so how do we use it?
Up next: a simple proposal.
