Platforms, Evolution, and Software's Cambrian Explosion

Last week, the New York Times reported on the release of Google Apps. The offering sounds pretty compelling:

[Rebecca Wettemann, vice president of Nucleus Research] noted that a business may spend about $80,000 on a systems administrator to manage e-mail and desktop office software. For the same amount of money, Google Apps allows a business to support 1,600 users, she noted. Simply in terms of staffing, “this may be a better proposition even if Microsoft were free,” Ms. Wettemann said.

As usual, your mileage may vary:

[Dave Girouard, Google’s vice president and general manager for enterprise] said Google’s products were not replacements for Excel or Word, which he admits are more powerful. But he added that for smaller businesses and for certain groups of employees within larger companies, Google Apps could be a substitute for Microsoft’s products.

That is to say, very large companies, organizations that care deeply about information flow, or teams that advanced features will continue to see value in more traditional offerings from vendors like Microsoft.

Of course, this news isn't particularly earth shattering. Tim O'Reilly, for one, has been talking about Software as a Service for many years. You can view this announcement Google Apps as part of an ongoing ballet between Microsoft and Google, Microsoft and the rest of the industry, or Google and the rest of the industry. Or you could view it further validation of the concept of software as a service, or of the web as a platform.


I look at it differently.

Computing is a young field, and still in the midst of its Cambrian Explosion. New platforms emerge periodically. Some platforms become wildly successful, while others fade away with nary an artifact of their existence. The web is certainly the most successful platform in recent memory.

A great platform, like the web, reinvents the industry: it throws out old assumptions, brings new tools and new practices to bear on software development, and makes the impossible not only possible, but ubiquitous. Most importantly, a new platform gives us a clean page to start thinking about how to build systems. Given a great new platform, greenfield projects become the rule, not the exception; the only way to truly adopt a new platform is to throw out the old applications and start anew.


Yes, greenfield projects that require scrapping the old and starting from scratch are a good thing. But there are a few caveats.

As Joel Spolsky points out, rewriting an entire project simply because it's ugly or poorly engineered is never a good idea. This is just the siren song of second system syndrome, and it should always be avoided. Joel points out that the Netscape engineers were wrong to embark on a grand rewrite project in 1998, and lists similar projects that attempted to rewrite existing code, all of which failed. (Had Mozilla been a commercial software project, it would have failed just as surely as Quattro Pro and Copland did. Mozilla succeeded in the long run simply because it wasn't a commercial project, and it had the luxury to take years to complete.)

These lessons simply do not apply in the context of Google Apps. Starting a desktop office suite may have been a good idea in the early 1990s, before Microsoft Office established its monopoly and dominated the category. Today, starting a desktop office suite from scratch is either foolish, insane or both (except when the laws of physics and economics are suspended, as in open source projects that take years to complete).

Why is Google's office suite special? Not because it's Google. The rules didn't apply because Google Apps isn't a "desktop office suite." Writing a office suite for the desktop is still a bad idea, for the same reasons it was a bad idea ten years ago. But Google didn't do that. They solved an existing problem on a new platform (and bought some key components to hasten the process).

This is precisely what PC software vendors did 25 years ago, with packages like 1-2-3, dBase, and WordPerfect -- provide new solutions to old problems on a new platform. This is why Google is clever, not stupid.

By solving an existing problem on a new platform, Google Apps sidesteps the need to maintain or mimic all of the bug fixes that took years to identify with Microsoft Office. This renders many of Joel's objections to software rewrites moot, and makes it not only feasible, but desirable to rewrite applications from scratch. The same is true for the thousands of apps that were rewritten in Java, Perl, Python, and other languages to move to the web, and move away from the bugs, constraints, and limitations of earlier platforms -- desktops, mainframes and dialup terminals.

Not only are these rewrites a good idea, but a rewrite on a new platform in a new language is an excellent idea, especially when those new languages offer a higher level of productivity.


Claiming the "new platform exemption" doesn't make a rewrite project instantly magical and wise. Plenty of platforms come and go without changing the computing landscape. If you lived through the 1990s tech bubble, you may remember Microsoft Bob, Windows for Pen Computing, Pointcast, Marimba, BeOS, OS/2, Newton, MagicCap, OpenDoc and Pink. None of these efforts produced a viable platform. In hindsight, efforts to rewrite applications for these platforms turned out to be a complete waste of time.

Rewriting a program from scratch to target a powerful new platform does make sense. This was true in the 1980s with the PC, the 1990s with the web, and today with the AJAXified, RESTful web. Looking at the software industry in this way, it's certain that new platforms will emerge in the future. Most of them will fail, but a couple may be so powerful that they change all the rules.


How do you prepare for the next great platform? Really powerful new platforms tend to come along with new languages, so being nimble and learning how to learn new languages helps. Sticking with a single language and platform is generally a losing plan for a lengthy career. The software industry is dynamic, and needs practitioners that are able to adapt quickly. Failure to adapt to changing market demands is a recipe for deep specialization, obsolescence, or entry into management.

Learning new programming languages isn't sufficient; NewtonScript may have been interesting for a while, but it was a total dead end. Many lackluster platforms were built around C++, and none caught the imagination like web stacks for Java, Ruby or Python. Pascal, xBase and BASIC were strong contenders in the early PC era, but now those skills are nearly to worthless. Environments like Smalltalk and Common Lisp remain some of the most powerful ever created, but they have yet to lead to a widely adopted platform; this may or may not be an important concern.

How should you choose which languages to learn? One way is to follow the trends, and see where the industry is moving. In the 1990s, objects were big and getting bigger, so C++ was a good place to start, at least until Java came out and simplified that model. Smalltalk was a better choice, since all of the key concepts to object oriented programming start there. With a background in these fundamentals, picking up new languages like Python, Objective C, C#, and Ruby much easier.

Today, there's a move to simplify object oriented systems. Closures are a hot topic, which means looking into functional languages like Haskell, *ML and Lisp/Scheme. Prototype-based languages are becoming popular, which means looking deeply into JavaScript, but also Io and Lua, or going back to the source and studying Self. However, if you understand class-based languages, prototype-based object oriented programming isn't a huge jump. Better to focus on a functional language instead.

Although I have a lot of respect for the ML and Lisp language families, my money is on Haskell (surprise, surprise). First, Haskell is directly influencing C# 3.0 and the other .Net languages, via new technologies like LINQ. Microsoft's C# team isn't alone here; features from Haskell are slowly percolating into Java and Perl as well.

Additionally, Haskell takes a strong stance on functional programming, by forcing programs to be pure and side-effect free. This approach can be quite severe, but it does have some key advantages. The lack of side effects leads to a shared-nothing programming model, which eliminates entire classes of bugs for multithreaded programs. And with massively multi-core/multi-CPU systems in the near future, a better threading model is going to be a key feature of the next great platform. Transactional support for threads via STM can't hurt, either.


While I'd like to say that Haskell has all the indications of becoming the next great platform, I don't believe it is. However, the next great platform is likely to be strongly influenced by languages like Haskell. Since we don't know what that platform will be, it's best to go to the source and get a sneak preview of what we should expect to see soon. That platform, when it arrives, will be another game-changer, making the apps we develop today obsolete, just as Google Apps is making desktop office suites obsolete today.