A month or so ago JP Rangaswami (confused of calcutta) mused on a challenge thrown out by Alan Kay - why isn't there a Moore's Law for software?

That question got me to thinking a bit, and as I promised in A Moore's Law for Software - Part One, here's a (very) modest proposal.

More on the Underlying Problem

When you really think about Moore's Law, it's a measure of raw capacity. Capacity, but not capability. It's the job of software to take that raw capacity and turn it into useful capability, but save that thought for later.

In the meantime it's easy to see how Moore's Law operates (raw, first-order capacity doubles every 18 months) when measuring stuff like transistors on a chip (the original), disk drive capacity, or perhaps network bandwidth.

But these three examples are not really the same anymore.

In a way they used to be more alike, back in the day when most applications generally ran on increasingly faster single processors. In other words, the increased transistor count on the processors basically translated pretty quickly into increased capacity for running applications.

But all that began to break down when the organization of those transistors became more complicated. The underlying limits to clock-times on the chips limited i/o capacity, memory bandwidth, and ultimately processor speed. In order to deal with that system architects and designers have always introduced forms of parallelization - pipelining, multiple data paths, caching, multi-cores, multi-processors - some of which are transparent to software, most of which are not.

The Struggle

Making use of the forms of parallelization that require a developer to take conscious action is not so easy. In fact, the mainstreaming of multi-core chips is bring this problem front and center ...

... where it is combining with system-level architects' desire to increase system level capacity and resiliency by making use of many individual processors, perhaps even commodity processors.

These meta-trends are combining with several others (uber-cheap hardware of all kinds, nearly unlimited network bandwidth, ubiquitous mobile devices, and more) into a "perfect storm" for application developers - where we are in danger of dying of thirst in the Garden of Eden.

In other words, we have an abundance of raw system-level capacity, and our apps still can't scale. Which leads me to my proposal.

A Moore's Law for Software

Software must be able to scale. Whether it's the latest web-scale social network, an enterprise ERP application, analysis for an intelligence agency, or video software on your iphone, apps must scale, period.

Except that most of the time applications don't do that very well.

While we all know that needs to change, and there is much attention focused in this area, I think we need to articulate this effort and give it a name, so here goes:

Blaise's Premise.

Software should be able to reliably make use of all raw capacity provided by the infrastructure on which it executes.

There, that's it. Perhaps we can call software that generally meets this criteria to be Blaise Capable, maybe even give it a nice little logo to acknowledge the capability.

A Few Questions Answered

Why Blaise? I'm proposing that we name this after Blaise Pascal, a brilliant 17th-century French mathematician and philosopher. I'm hoping that he might find this little idea interesting someday.

Why a premise? Because I think we should just be able to assume that software scales. While I know that our industry is a long way from that goal, and that the stuff that stands in the way of this is legion, it is most definitely a worthy, and increasingly achievable goal.

Why not a measure of capacity? Because software is abstract, malleable stuff. There are no fundamental "units of software capacity" that span the range of applications and remain constant over time, and I do not think such a thing is even rational to consider. Let the hardware guys provide the capacity, and leave it to the software industry to transform that raw capacity into useful capabilities. Blaise's Premise is essentially a statement that this transformation should be efficient - 100% efficient, ideally.

A Request

This is the great struggle in which we find ourselves in this industry, for many different forms of software. Those who can do this well, and who make it very easy to do for a wide range of software and system architectures, will likely prosper. Those who cannot ... well, there's always some nice vineyards in Napa to explore.

At any rate, I'm open to suggestions and comment. If you like this idea, please spread it around - I think it will help our industry focus on the need to create software that scales easily and reliably.

Perhaps then we will begin to fulfill the promise that computing has contained all along.