More and more I get the feeling that we are seeing the beginnings of a revolution in the way software is developed and deployed.
In the (very) old days we had applications running big mainframe computers with the user interface either being a stack of punched cards (batch programs) or some sort of dumb terminal connected to the mainframe.
With the advent of PCs computer applications quickly moved to the desktop (even though early PCs didn’t have a desktop) because it gave the user more control and, most importantly, it gave the user more responsive and interactive applications. The mainframes hung on as long as they could with client/server applications but, in the end, they just couldn’t compete with the desktop.
The move to desktop applications brought with it some new problems that required changes in the way software was developed and deployed. These mostly had to do with things we now consider to be rather mundane: how to keep track software versions; how to push new versions (or bug fix patches) out to user; how to deal with multiple, (possibly) incompatible releases out in the field; how to plan and market new releases; etc.
The next big change was caused by the Internet. While the major benefit to the user was the connectivity – the application and its data is available anywhere, any time; and applications can talk to each other and cooperate for the user’s benefit – it also returned us to some of the benefits of the old mainframe and client/server applications. New software versions are deployed to a central server and immediately available to everyone without them having to do anything.
Of course, the move to the Internet also brought with it some problems. The biggest one, from the user’s point of view, was that those nice, responsive desktop applications had turned into slow, clunky, page forms—every application became a series of form pages instead of a series of intuitive interactions. The user also lost control of their data, but most user’s didn’t mind or care (until, that is, the provider of their application went out of business and took the user’s data with them).
We are now in the beginnings of the next big change. Internet applications are increasingly enabling interconnectedness through public APIs, allowing new applications to be built on top of them and/or aggregating the services of other web applications. They are also starting to use AJAX techniques to regain some of the interactiveness of desktop applications. Collectively, these (and other) factors having been loosely termed Web 2.0.
That’s the public side of the Web 2.0 revolution. The part you don’t see (or hear much about) is how this Web 2.0 revolution is affecting the way software is being developed. It turns out that this is just as much a revolution as Web 2.0, itself. Marc Hedlund, from O’Reilly, recently laid out his accumulated observations on this new Web Development 2.0 revolution. This is very interesting stuff, and I get the nagging feeling that this is just the beginning.
Software isn’t written for Web 2.0 companies the way it was during the bubble, nor is it written the way traditional, shipped software was. New ideas about Web applications seem to necessitate new ways of making those applications. Below is my current catalog of observations.
As Dion Hinchcliffe said, “Compelling stuff but scary for us used to the old ways of things.”