During the Microsoft’s PDC 2008 conference, a new technology platform was unveiled by Microsoft dubbed Microsoft Azure.

Unsurprisingly, there was a lot of confusion surrounding Microsoft Azure. The sheer variety of features, interfaces and details that are part of Microsoft’s Azure made things hard to grok. But in the end, I think the core concept is actually simple and it actually is a fundamental building block for software applications of the future. Here’s my take.

So what is Microsoft Azure?

Azure is a software development kit (SDK) as well as the runtime environment for building and running highly scalable applications for the cloud.

How is it different from normal frameworks?

From a developers perspective, Azure is no different from the .NET runtime or from the C++ runtime or the Java runtime. Instead of the application being executed on your local machine, the application actually runs on the “Cloud” (in this case Microsoft’s Datacenters).

 Why do we need Azure?

If you read my previous post(The future of software applications), clearly the trend is towards migration of software apps from the desktop to the cloud, running via the web browser. The desktop is becoming more and more irrelevant today and the OS that powers the desktop matters even less.  The next big thing is already mostly upon us and it is web-based applications. The good news with web-based applications is that you don’t need to worry about a lot of things that you needed to worry about when developing desktop applications. The bad news is that you now need to worry about a whole host of other things, security, scalability, infrastructure management, bandwidth costs etc. And building these kinds of applications correctly is difficult, not to say sometimes almost impossible.

That is where Microsoft’s Azure comes in. By building applications for the Azure platform, which abstracts these problems away from you, it promises to make developing scalable web-applications as easy as developing desktop applications.

How is it different from Amazon’s EC2 or Google’s App Engine?

As a general concept, it is not wholly different, but the whole integration of various services + the advantage and productivity of using Visual Studio to build apps appears to make the Azure development platform attractive to legions of developers who work with .NET. Amazon’s EC2 allows any kind of technology to be used within the virtual machines that are deployed, while Google’s AppEngine currently requires applications to be written in Python.

What does this mean for the future?

In one way, Microsoft’s Azure platform actually tells you that Microsoft realizes that a lot of applications are going to migrate over to the web. This means that their traditional dominance of the desktop is going to wane as the desktop OS matters less. However, they have also correctly realized that by providing a development platform for the web, they can be dominant in the emerging software platform of tomorrow. In my opinion this is a brilliant move. A lot of companies today are trying to get market and mindshare by writing the web applications (Google Apps, Photoshop Express and others etc). Meanwhile Microsoft skipped that and wrote the platform *for* writing web applications. It remains to be seen how easy the Azure development environment is to use, but if it is even only 10x as hard as writing a .NET applications there will be a lot of applications running on Microsoft Azure.

However, I think that the other big companies are not going to keep still. Microsoft’s Azure is the opening gambit for the fight for the platform of the future. It is now clear to all the big players what the fight is about. Even if Azure is not successful, I think that this is an important turning point in the history of software applications.

That is really the million dollar question everyone wants the answer to. Being at the right location at the right time pays off immensely especially if you are in the start-up business.

Some History

To make sense of the direction that software is going, one needs to study the evolution of computing. Evolution in living organisms (if you remember your Biology) happens due to environmental mechanisms that favor one form vs another (aka natural selection) as well as due to small random changes to existing forms that might get passed down from one generation to another (mutation).

The analogy of software applications to living organisms breaks down at several levels including time (a few billion years vs about 50 years) but it still is a useful model to use.

Early computers were monstrous in terms of size, cost and inefficiencies. And it was almost impossible for computers to exist without an army of attendants keeping it alive. Over time, major advances in technology, the invention of the transistor, improvements in manufacturing etc made computers affordable by big corporations, most Governments, then by medium businesses and finally by almost everyone. This was the Personal Computer revolution, which wrenched computing power from huge central servers and distributed it to the hands of the individual user. For the first time, a person could do what he wished with his machine without affecting anyone else. For the first time, he needn’t get a time slot for doing computing; the computing resources were his alone, waiting for him to use. This was the Personal Computer.

The advent of the PC (and macs) lead to huge strides in computing. Users free to tinker with the hardware and software figured out innovative things to do as well as started demanding more and more from their machines; from dot matrix printers to color laser printouts, from command line interfaces to rich GUIs, from primitive pixelated games to full blown virtual worlds, the changes were tremendous. This evolution was so rapid that a PC about a couple of years old became obsolete and unable to run latest applications.

The Internet

However a small mutation appeared, that completely took PCs into a completely new direction. The Internet. The Information Super-Highway. The World Wide Web. A simple protocol over a copper wire (HTTP over TCP/IP) changed the history of Software Applications.

The Internet started out humbly as a communication medium for people to send simple messages (email etc) to each other. With HTTP and Web browsers, it became a means for people to access, disseminate information effectively.

The key driver behind the web was information, whether it be a recipe for a favorite dish or figuring out the reason the PC won’t post from reading myriad forum posts. Because the information was so easy to access and could cross operating system walls unfettered, more and more people realized that the WWW can actually become a platform than just a conduit for information.

The Browser is the new PC

Along with this development came a lot of other economic changes which drove most desktop application developers out of business (except for the big software companies like Adobe etc). The factors were many, but one of them was the growing realization by software developers that building software applications for the desktop has lot more perils than building applications on the web. The perils included rampant piracy, almost impossible to administer software licensing, increasing competition from open source and free software and so on. On the other hand, building (good) web applications was (and is) a several orders of magnitude harder than desktop apps, but there was far less chance that what you build will become useless or pirated. Once consumers started using the application and invested some time and energy into it, they were bound to remain loyal, held captive by the immobility of the data. This sounded like a brilliant business model for many companies.

To consumers, on the surface, this seemed good too. No more worrying about installing applications, just do it all from Internet applications. Upload all your files/photos/information into online services and access them anywhere a browser works. The allure was unmistakable.

It is the scenario that we find ourselves in today in late 2008. Web 2.0, AJAX all lead the charge in promising the new internet. You know the old world is crumbling when Adoble previews a new Photoshop application running on the “Cloud”!

So have we now come a full circle? We went from huge servers to completely independent standalone PCs and then back to huge server farms. For most people a day on the computer has become synonymous with using the browser. Reading email, news, writing a document on Google Docs etc. (A browser has become what Emacs used to be, the center of the computing universe).

But Look Ma, I got all these cores!

So most new applications are definitely headed towards the “cloud”. Almost all new exciting apps/ideas you hear about will somehow or the other use the HTTP protocol. Developers love it, consumers do too and what more do you want?

That brings us to the next interesting question. What about all this horsepower we now run under the hood of our PCs? Core 2 Duos, Core 2 Quads. All pretty powerful, but pretty much useless if a browser is limited to making no more than 2 connections at a time to the web server and almost all the heavy lifting is done by a server on the server farm.

But then the hardware companies assure you - “hey! you need to buy the latest machine so you can surf 5x faster”. It cannot be farther away from the truth, since without changing your network connection for instance, you are not going to do anything significantly faster. I can attest to this personally as I am owner of a laptop that is more than 7 years old which can browse the Internet and be perfectly usable as my new screaming fast Core 2 Quad. Go figure! So where does this leave the hardware manufacturers? In a pretty hard place. It is becoming harder to convince anyone to upgrade to the newest hardware. Also because CPU improvements have been increasing number of cores and not raw CPU speed you are going to see far less improvements in performance (Remember: Most software still don’t take advantage of multiple cores). You are probably better off upgrading your network and connectivity.

And Operating systems? Well they matter even less these days. Almost any operating system offers almost the identical experience if all you are seeing is the borders of Firefox all day.

But what about Games?

And so I believed too that games alone will stem the time against web applications. But here too things are changing. Not many standalone titles are being released these days on the PC. The consoles are where the action is. Of course, there will always be RPGs that can never be played on a console, but those are few and far between.

The new direction towards some form of central server based applications have affected games as well. Look at the World of Warcraft and the other MMO games available. The game companies have finally figured out that online games are the perfect anti-piracy mechanisms.

Are we done yet?

So if all I have said seems to imply that the future of software applications is in the “cloud”, you might be right. That’s the future the big software businesses want to take the consumer towards. That’s the direction of the most profits, maximum control and complete lock-in. That’s the direction most of them are going toward.

But there are a few of us out here who believe that this is not the direction that is the most beneficial over the long run for the average user. What you get from web applications, you lose in reduced freedom and the erosion of privacy.

Trading up privacy and security of your data for the convenience of anywhere access doesn’t work. The scales don’t balance. Most people don’t see the threat yet or the incredible potential for misuse.

What we need is something that balances the risks and rewards. We need applications that offer customers the accessibility of web applications with none of the risks. We want applications that can leverage all that computing horsepower to the max instead of rendering a paltry few pages every few minutes. We need applications without boundaries, that empower customers in the connected world. That might not be the future that businesses want, but thats the future that consumers will want.

Tonido is a small step closer towards that future.

… must be the worst thing any self-respecting Software Developer would advocate. However, there is some truth to the statement. Allow me to explain.

Software development has been so many times compared to building construction, that the analogy of blueprints to software design is accepted without contention. Authoritative sources claim that no one would start full construction without the blue prints drawn up.  And it follows that we need software designs before construction.  This is all in the realm of conventional wisdom, that is inscribed and drilled into every developer’s head from the beginning of time.

But my experience was always different from this wisdom. I always found that even when software design was complete before starting to code, invariably(100%) the design would change as the code was written, the test cases written, the test cases run, after real world use. The shipping product’s design would only have a passing resemblance to the original design.

This evolving design troubled me to no end. How can a software development as a construction analogy be valid if the design evolves? I am not aware of any construction practice where the blue print changes as the construction proceeds.

The conclusion to draw is that “the design is the blue print” analogy is fundamentally flawed and incorrect for software development.

So what then is the blue print for software if it is not the design?

It is the source code itself says the insightful “Code as Design” articles published by Jack Reeves.

And, not any source code, but the source code AFTER it has passed through unit, system testing, QA, acceptance testing etc. The blue print for software is what goes into the build for the release.

This is a subtle but an important change in perspective. The important thing to realise is that software design is not complete till the code is written, all the tests pass, the QA is complete and the product is shipped to the customer. Each and every step along the way requires the same skill and importance as that is usually paid to Software Design.

Note, that this is not saying that there is no need to design first before coding, but rather, design is not a fixed phase that stops before coding begins.

Code first, Design Later.

Consumer’s expectations in general always increase over time. This is inevitable given the relentless march of progress and is no different for software. Any modern software system that is worth its salt these days, has to support a whole host of features. One of these must-have features is patching.

Patching, sometimes also called as automatic updates comes in many different guises in the software world. These start from ubiquitous software updates in OS’es like XP, Vista, Ubuntu to other common place software like Anti-Virus, Firewalls, Office suites and so on. Designed well, these updates help the user keep abreast with changes, reduce technical support, keep the system secure and so on. Designed badly, they turn into a nagging system that constantly chastises you for playing hooky and not upgrading. It forces the people who know how, to turn on options like ‘never check for updates’ thereby defeating the whole purpose of auto-update systems.And it forces the people who don’t know how to always click on these pesky message box reminders EVERY SINGLE TIME they interact with the software. This doesn’t win any enthusiastic supporters does it?

So if we are trying to create a software patching system, how and where do we start? Here’s a set of requirements:

1. Easy-to-use, minimal user intervention when automatic updates are enabled
2. New version notifications should be in the background
3. Works (or fails gracefully) in non-admin mode
4. Supports incremental patching
5. Secure
6. Easy to administer and manage software patches

So, let’s start going through these requirements in detail:

Easy-to-use

The software patching system has to be essentially invisible to the end user. Especially, if automatic updates is enabled, every time the system is updated, there should be little or no effect to the end user. This makes for an overall good experience. A good example of this kind of turn-it-on-and-forget-it kind of patching system in use is in Firefox. I haven’t had a time that the firefox update failed or I had to do some additional work. It automatically detects that it has updates and next time I restart firefox it applies it and restarts itself. This is what I would call unobtrusive.

New Version Notifications should be in the background

This requirement doesn’t sound like a big deal, but *many* programs do this and make the decision for you that everytime you open the program you are interested in mainly knowing about the latest update. Most times it is not. The user is in the program to do some work. They would care less if they were running 1.0.1.2 vs 1.0.0.8 as long as they are able to get their work done. Some programs are slighly better in this regard, allowing you to change the behaviour of the notification to be less obnoxious, but the default is set to be obnoxious. See example below:

On the other hand, see Wordpress’s update notification, not obnoxious, but still useful.

Now, I can see a few people objecting to this saying that if the system requires a high critical update, this update notification should be shown to the user first thing, come what may. Yes, I agree, you need to show this to the user, but not push it down their throat, for example showing this via a Modal dialog still is bad. Just because you pushed this down the user’s throat doesn’t mean that the user wants to update the application right at that time. If there are security implications, it is still his decision to take that risk.And the software application has to respect that, irrespective of whether it doesn’t match it’s objectives.

Works (or fails gracefully) in non-admin mode

In the Windows world, most users have been conditioned and accustomed to running as an Administrator. This is mainly because most software (including mine) have assumptions about several things including, write privileges to the Program Files directory. Normally, writing to the Program Files directory is only possible when a program is running as administrator.

When an update program runs it has to consider the fact that the user could be running with limited privileges and either detect and handle this error gracefully or work around it.Either way, the update should either succeed or fail. If it failed, the user should know precisely why. Most times, software that fails this way reports a cryptic error message that no-one except the developer can figure out.

Supports Incremental Patching

This is somewhat related to the ease-of-use thing. Most patching systems, neatly sidestep the whole update issue, by downloading a brand new installer and starting it when you click on “Update Now”. One of the reasons this is bad, is inefficient use of bandwidth. Most applications when they are being updated just change a few main files. Very rarely do all the files require changes. So downloading a full application installer is inefficient not only for the user’s bandwidth, but also to the the server that is hosting these changes.

The other reason, having the full installer downloaded is the confusion created. Most times it is not clear whether the software should be uninstalled first before starting the installer or whether the installer will take care of this for you. I cannot count the number of times that after the installer churns away for a few minutes will abort the install saying that the previous version needs to be uninstalled first. Aargh. The other reason this doesn’t make much sense, is because this approach won’t work for software installed for example on USB keys.

The best patching systems allow incremental patching, i.e. downloading only files that have changed and applying them. This reduces bandwidth, removes confusion on installers and works on portable sofware.

Secure

Needless to say, security while dealing with patching systems is imperetive. For example, the software should not be misled to download software updates from an attacker and install them on the user’s machine. This is especially important in these days where even DNS poisoning attacks can fake the location of the webserver.

Easy to administer and manage

This requirement is not from the user’s side, but purely focused on the developer and operations. Creating a patching system satisfying these conditions is not too hard, but creating one that is easy to manage and maintain is actually more tricky. Over the lifetime of a product, hundreds of patches will need to be created and maintained and quickly this becomes a full time job for the unlucky person. For example, RTPatch, an incremental binary patcher can create differential patches given two binary files. But then if you have N versions of your product, every new version will require patches from all previous versions to move to this latest version. This becomes unmanageable.

The correctly designed patching system alleviates this problem.

It is tremendously hard to design good UIs. It is an art, and no one knows exactly what ingredients go into the broth to make it tick.

On the other hand, everyone knows how to recognize bad UI design. Bad UI at best annoys you and and at worst makes you so frustrated that you mostly give up using the program even if it has other merits.

Here’s an annoyance in IE 7.

See the same browser window in

IE6

Firefox

Safari

Netscape

What is wrong with the three sections marked in red in IE7? Those buttons are the most often used functions in a browser. Any browser. See how the buttons are laid out in every other browser.

So what is the problem? These buttons are spread out completely in different sections of the browser. There is no rhyme or reason to it and it is baffling to me why this change was made. So whenever I browse in IE 7, I always struggle to figure out where those buttons are. I keep clicking the wrong places to do the things I have been used to doing in every other browser by the sheer force of habit.

The UI history of all browsers that have been released over time have pretty much standardized the location of these buttons. So the change in IE7 makes it harder to use.

UI design is black magic. It is as if the best GUIs had a few voodoo priests hanging around, casting wards against the “Sucky UI demon”.

Here is a quick UI design cheat sheet, freely copied from various resources. I suggest you read those resources in full to get the full gist of the ideas.

1) ‘Don’t make me Think!’

UI design has to be about this. Read the book ‘Don’t make me think!’ by Steve Krug. Users want to do as less as possible in the smallest time possible. They don’t want to read a ‘manual’. They don’t want to read documentation. They would rather spend time randomly clicking on things to see what they do instead of reading documentation. It is like asking someone for directions, people would rather drive around wasting significant amounts of time trying to locate someplace rather than stop and ask directions and appear lost.

2) ‘Match the Mental Model’

When a user uses an application, he has a fundamental model of how he expects the application to work. When it matches him with that mental model quickly, then things gel and he is happy. Conflict occurs when the application doesn’t match the mental model or worse it has a completely different model and requires the user to understand its (crazy) way of doing things. Most users have no incentive to put up with that. (Unless in some complex domain like 3D modeling, FET  where there are no obvious mental models)

3) ‘Don’t reinvent things that users already are familiar with’

There is a good reason Microsoft/Apple have a consistent UI model. Every window has the same familiar elements, minimize button, maximize button, menu, scrollbars, buttons, radio buttons. And for the most part they look the same in every app. This helps tremendously because people don’t have to re-learn a new UI paradigm and widget set.

So for example, when a UI widget is clickable, it has to look explicitly clickable and not look like some fancy woozy thing that looks clickable, but when clicked, does nothing or something that doesn’t look clickable, but when clicked, actually does something. Every time a user experiences behavior that is unexpected to what he expects, he gets frustrated. Over time these frustrations add up and he will discard the UI because it is not ‘easy to use’.

4) ‘Don’t make me choose’

Users are lazy. They are not interested in understanding every nuance before making a decision. So when we provide too many options in a UI a user will get frustrated. The corollary is ‘Use reasonable defaults and let the power user change them if they want’. Most people don’t want to be power users if they don’t have to.

5) ‘Keep it simple stupid KISS’

The more busy a user interface looks, the more frustrating it is for users to understand and use it. The number of things presented in the UI should just be enough to get the job done and not any more.

6) ‘Test Test Test’

UI debates can be religious and there can never be a right or wrong answer, however the best way to resolve it is to do usability testing and ask opinions. Experts claim 5 or 6 users are sufficient to give good feedback.

That wraps up the list.

References:
[1] http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html