Philip Brittan's Blog

Community Archives

The Battle Over Java

Is the cold war between Sun and IBM over Java heating up?

I often rant about the epic battle that is brewing between Java and .NET. But there is another battle, not necessarily less significant, that has long been brewing within the Java camp. It is a battle between Sun and IBM over the control of Java. Although the two have long been fierce competitors in the area of systems, the struggle over Java has so far been largely a cold war, veiled under a veneer of cooperation.

But recent moves have brought the battle more into the open. Since Sun decided to make Java an “open standard” and turn its stewardship over to the JCP, Sun gave up a certain level of control over Java. But it still retains sole rights to the name and gets to decide what is called Java and what is not (this is the same leverage that Linus Torvalds holds over Linux). Earlier this year, Sun made the decision to become more aggressive about exerting that right by renaming its core product stacks the "Java Enterprise System" and the "Java Desktop System", even for components that have little or nothing to do with Java. This move angered a number of Java partners, but Sun undoubtedly hopes that it will more strongly tie the identity of Java to Sun.

The other open battle is in the area of Java tools. IBM and Sun each push toolsets that are built on open source foundations -- Eclipse for IBM and NetBeans for Sun. There was talk about Sun joining the Eclipse consortium, but now Sun has made it clear that it will rather support NetBeans to the bitter end, and is instead arguing for a standard to improve interoperability between tools from different vendors, a proposal that IBM has rebuffed. Aligned with each of these tools is a separate GUI toolkit -- Swing for Sun/NetBeans, SWT for IBM/Eclipse. The passions surrounding this schism run deep. At a recent conference, I witnessed Swing developers vociferously laying into IBM execs about IBM's insistence on building Eclipse with SWT, even though Eclipse can build Swing applications.

The battle between Sun and IBM certainly predates Java, and even today it ranges beyond Java. Web services and support for Linux are two other areas in which the two systems companies have been engaged in open and behind-the-scenes tussling.

For us who develop in Java, the critical issue is what bearing this battle will have on the future of Java and whether it will weaken Java in the face of an onslaught from Microsoft .NET. Java is a grand experiment. Is it possible that many independent vendors, who normally compete with one another, can come together and work for the betterment of something as complex and with as many facets as Java? The answer to that may be key to whether the larger grand experiment of open standards for software will prevail.

Confusion between grid and utility computing

I just published an article on CNet News.com titled The new IT confusion which attempt to disentangle grid and utility computing concepts in less than 700 words.

Open Standards Definitions

What do we mean by open standards anyhow?

My last entry evoked a certain amount of name-calling in the arena of open standards. Today I'd like to explore just what "Open Standards" might mean. This will seem very simplistic to many of you, but I hope it’s helpful to sort things out in a simplistic way.

I’d like to start with some definitions:

Open - Open for third parties to support and create products to (opposite is Closed)

Proprietary - Legally owned by a company, individual, or private group (opposite is Public Domain)

Community - Administered by a group, not just a single company (opposite is Sole-Stewardship)

One minor note that some people seem to miss is that open and proprietary are not opposites. A standard may be both open and proprietary at the same time. A "closed standard" is an oxymoron. You can have "closed systems" which do not allow third-party integration, but you cannot have a meaningful closed standard.

A standard that is not legally owned by any company or person is said to be in the public domain. Examples of this include: HTML, SNMP, etc.

A proprietary standard is owned by a single company and may be administered solely by that company, as Windows and Solaris APIs are, or it may be administered by a community, as Java is. Some communities are have their own bodies for collaboration (JCP), and some rely on standards bodies, such as the W3C, OASIS, ECMA, and so on, to handle community collaboration and be the official keepers of the spec.

An "open source" standard is one in which the source code as well as the APIs are included in the specification of the standard, meaning that third-parties can extend the product at the source code level, not solely by working through an API. Open source is considered by many to be the purest form of open standard. But again, that doesn't mean it can’t be proprietary. Linux, a favorite open source example, is not in the public domain. The Linux GPL license does not require a monetary fee, but it does make other requirements which it imposes with a copyright. For instance, all source code for modifications made to Linux must also be freely available. Linus Torvalds explicitly owns the registered trademark "Linux". FreeBSD, as a counter-example, is also free of charge and open source, but does not impose the requirement of sharing enhancements with anyone else.

Whether software costs money, and what it costs, are economic/strategic decisions made by the owners of the software / standard. 0 is a price, just like 5 or 745. 0 just carries more psychological weight than other numbers. The underlying license and source code for Linux are free, but distributions of Linux do not have to be free. Companies can charge whatever they want for them.

The relative advantages of these are not moral. They are rooted in various benefits they give to the owners and users of the standards. One of the benefits of using open community standards is vendor-independence: multiple vendors can create competing products that implement the same standard, thus giving customers more choices. Cost, ability to extend, and ability to debug are common reasons that customers choose open source software, but keep in mind that many “closed-source” solutions do provide source code to their paying customers for debugging purposes. One might say that a sole-stewardship standard carries the risk to users that the single company administering the standard can potentially change that standard to suit only its own needs, thus causing damage to third-party users of the standard. Conversely, since a community-administered standard must reflect the interests of a group of different constituencies, it is unlikely to change capriciously or quickly. This distinction is the heart of the Microsoft / Java war of words.

The flip side of that is, of course, that since community standards are slow to change, single-stewardship standards can be much more nimble and capture the changing realities of the marketplace in a more time-sensitive way. When a standard is too slow to change, then vendors supporting the standard are sorely tempted to add one-off extensions for functionality that is not yet standardized, which erodes the value of the standard.

Customers make choices about their adherence to standards based on what they need to achieve and the risks they perceive.

ROI of UI Technology

I recently wrote a paper for The SAP Developer Network on user interface technology in the enterprise. I'd like to pull out one small section of that paper for further discussion here:

There are three main factors that affect the ROI of any UI technology: ease of use of the application, ease of deployment and on-going maintenance, and ease of initial development. Based on the total cost associated with each of those factors, they should be assigned the following order of priority:

1. Ease of Use: The usability of an application affects the bottom line of a company every day and that effect is multiplied by the number of users the application has.
   
   
2. Ease of Deployment and Maintenance: The costs associated with the deployment and maintenance of applications affects a company’s bottom line on an occasional but usually repeated and perhaps regular basis. These costs are incurred whenever an application needs to be deployed to new users, upgraded with new features, and have bugs fixed.
   
   
3. Ease of Initial Development: The costs associated with the initial development of a new application affect the bottom line of a company only once per app, and they scale with the number of developers involved, which for the vast majority of applications is far less than the number of users of the application.

The temptations of the immediate gratification of fast initial development can be so strong, in fact, that some UI development tools focus entirely on the ability to put together a good-looking but simple application really quickly. This is valuable for getting early user feedback. However, many of these rapid development systems are ironically difficult and time-consuming for creating sophisticated applications, because of an inherent lack of flexibility. A good UI technology will enable rapid prototyping but won’t do so at the expense of production version development.

Therefore it is imperative that companies apply sufficient discipline in their technology selection and implementation to ensure that an economically correct ordering of priorities is followed.

Embrace, Extend, Extinguish on the browser?

Is Microsoft ready to move onto the 'extinguish' phase with the Web browser?

Microsoft is renowned for its "embrace, extend, extingish" strategy which involves enthusiastically embracing and championing a new standard, as a way to become the market leader in that standard, then extending that standard with proprietary technology that lets Microsoft lock in customers and lock out the competition, and lastly to let the standard die on the vine or be replaced by an entirely Microsoft-proprietary alternative. Microsoft has famously done this with Java, which in its final stage has now been replaced by C# in the Microsoft view of the world.

In an earlier post, I suggested that Microsoft makes money from Windows desktops, not browsers, and that a powerful browser platform is in fact a threat against the Microsoft-preferred fat-client model which is more firmly symbiotic with the Windows desktop.

It seems there is growing evidence that Microsoft may in fact performing a slow embrace, extend, extinguish on the Web browser.

Embrace: When Netscape introduced the first commercial browser, along with the promise that the Web would make the desktop environment irrelevant, Microsoft quickly jumped to develop Internet Explorer and used a wide array of competitive tactics to ensure that IE grabbed overwhelming share of the market and eventually pushed Netscape out of business.

Extend: For a while, Internet Explorer supported all the W3C standards for Web pages, but also added its own additional capabilities that let Web designers do things that the official standards did not support. This seemed like a helpful feature for developers, but had the inevitable effect of locking developers in to the IE platform. I recently met with an ISV that has a Web-based application that depends on the IE 6 extensions. This meant that the ISV required all their customers to access their application through IE only. But now, since a significant segment of this ISV's customers use Apple Macs, and since Microsoft no longer supports IE 6 on the Mac, the ISV is left high and dry.

Extinguish? I read an article this morning titled "Has Microsoft Forsaken IE?" in which developers complain that Microsoft is falling behind in supporting new Web standards.

"While it is true that our implementation is not fully, 100 percent W3C-compliant, our development investments are driven by our customer requirements and not necessarily by standards," said Greg Sullivan, a lead product manager with the Windows client group.

When it was pointed out that the most vocal critics of IE's CSS support are Web developers and authoring tool makers, rather than standards bodies, Sullivan said those critics were comparatively few.

Open Standards: Apps and Infrastructure

One valuable capability of open standards is to let customers decouple application decisions from infrastructure choices.

I recently spoke at a technology conference as a part of a panel, and one question from the audience was about which open standards were most important. My response was that there are many important open standards, but that one crucial capability that customers are looking for from open standards is the ability to make application decisions independently from infrastructure decisions.

The reason it’s valuable to be able to decouple those two decisions is that they are typically made by different groups within the enterprise and they are made for different reasons. Infrastructure decisions are made by the IT organization and are based ideally on price / performance. Application selection is typically made by line of business users, and functionality is the primary driver.

If a company cannot treat each of those layers independently then an application decision becomes simultaneously an infrastructure decision, which means that all the factors of functionality, price, and performance need to be considered together and the decision needs to be made by a combination of business people and IT folks, which complicates the process and potentially ends back up in “silo” structures that companies today are trying hard to escape.

Avalon: A new UI for Windows

Avalon gives Microsoft an opportunity to demonstrate its leverage over the user experience and to shake up competitors.

There is a lot of buzz in the Microsoft community these days in advance of the first public educational events around 'Avalon', one of the many new pieces of the Longhorn version of Windows. Avalon is the new Windows API, and it apparently represents a major jump in UI capabilities. Part of its value proposition is in the ease of use to developers and part in the experience for end users.

In order to increase developer productivity, Avalon will rationalize and reduce the number of APIs in the Win32 stack from over 70,000 down to 8,000.

On the user experience side, Avalon will feature advanced support for 2D and 3D vector graphics as well as standard GUI widgets. Some descriptions of Avalon suggest that it is more comprehensive than just the graphics layer, and will incorporate support for paradigm-shifting "task-oriented" UIs.

Microsoft has already said that they will be releasing a version of Microsoft Office for Longhorn based on Avalon, which should help drive user demand for Avalon’s capabilities.

I see several immediate ramifications for this:

1. It is a shot across the bow of Macromedia Flash MX. Flash has traditionally been focused on adding real-time vector graphics to Web pages for decoration or on-line advertising. Microsoft played along with Macromedia, bundling Flash into IE, because it never really cared about those fluffy things. But in the last year or so, Macromedia has been actively re-positioning Flash (now called Flash MX) as an alternative for building the user interfaces for enterprise applications -- smack into Microsoft’s home turf. It has been inevitable that Microsoft would respond at some point (there were early rumors that Microsoft might even try to buy Macromedia), and now it seems to be doing that with Avalon. Even though Longhorn isn’t due out until 2005, the mere fact that Microsoft will be baking into Windows the same kind of real-time 2D and 3D vector graphics capabilities that Flash promises, nicely integrated into same API layers as standard GUI widgets, could create enough FUD to slow down companies considering Flash MX. The fact that Flash is a client-side UI execution engine, just like Microsoft technology, means that it doesn’t have a strong differentiation over a Microsoft offering. Strategically, Microsoft can potentially always turn off its bundling deals with Macromedia, leaving them high and dry.
   
   
2. Introducing a major change in the UI API means giving Java a good shake. It is likely that it will take client-side Java long time to support the new capabilities of Avalon. If Microsoft can get its users addicted to the new paradigm (by using it in Office, which they plan), then they make Java look even more out-dated on the client side.
   
   
3. As I have argued elsewhere, Microsoft doesn't really like the idea of browser-delivered apps because it weakens the Microsoft desktop. Just as with Java, if Avalon gives users an amazing experience which is just not available through the browser, then browser-based apps don't seem like such a good idea to users. Alternatively, the browser might support these capabilities, but only through IE when powered by IIS on a Windows server.
   
   
4. Longhorn requires hefty hardware support, so Microsoft will undoubtedly time release to coincide with a price/performance level for new PCs that will allow them to encourage a massive hardware churn. That means that the Longhorn release will likely be coordinated with hardware partners like Intel and Dell.
   
   
5. The depth dimension of the desktop is catching on. Sun’s Project Looking glass uses depth by letting users angle windows away from them, thus using less of the 2D space of the desktop while still giving users an oblique view of what’s in the window. Microsoft’s new desktop, Aero, which relies heavily on the capabilities of Avalon, also makes more use of the 3rd desktop dimension by supporting transparent windows (so you can see the whole stack underneath at once), and also supporting real-time window rotation.

Of course, a rich thin client technology could take advantage of all the advanced features of Avalon and still let the business logic be powered by Java.

Microsoft and Web Services

Web Services are a way for Microsoft to leverage the existing base of J2EE without having to do anything to support Java explicitly.

In his article, "Why Microsoft needs IBM this time around", Mike Ricciuti argues that "Microsoft needs IBM to legitimize .Net and its entire development plan as a truly cross-platform strategy." While I think that both IBM and Microsoft sincerely want to make a case for the power of Web Services and to demonstrate that it is a cross-vendor effort, I think that neither does Microsoft needs IBM to help drive sales of .NET nor does IBM have any interest in legitimizing .NET.

Web Services and .NET are two very distinct things. Web Services is an open standard for programs to exchange data over a network. .NET is Microsoft's proprietary application development and deployment framework that happens to use Web Services as part of its approach. IBM can support the former without supporting the latter.

Web Services are in fact starting to take off. A number of customers that I work with have started to adopt Web Services as both an internal IT transport layer and even also as a way to make content available to business partners (in very contained ways so far). The fact that Web Services have not yet completely transformed the world by seamlessly interconnecting all supply chains and other business partner relationships is simply a result of:

1. the fact that it take a long time to adopt any new technology, and Web Services is still very young in the grand scheme of things.



2. there are still a lot of issues with Web Services that need to be worked out to make them practicable in the large. Specifically, Web Services need more management, orchestration, transactional efficiency, and security support. These are exactly the areas in which IBM and Microsoft made a commitment last week.

.NET is also being adopted, even without companies necessarily buying into the grand plan for Web Services. So far .NET’s success has primarily been a tools success -- Visual Studio developers are upgrading to Visual Studio .NET. However, I have come across several large Java-oriented enterprises that are now planning on building .NET Smart Clients to their J2EE back-ends because they feel that Java has not given them a viable alternative on the front end.

I suspect that Microsoft's peculiar interest in Web Services is a way to leverage the existing base of J2EE installations in the market without having to do anything specific to support J2EE (which would be anathema to MS). I have argued in an earlier entry that Microsoft plans to use its domination of the desktop to push the client side of .NET and then to use the domination of client-side .NET to push server-side .NET. The challenge that Microsoft faces is that many large corporations currently have big investments in J2EE -- if Microsoft forced them to turn their backs on those investments in order to adopt .NET, then client-side .NET would face a lot of extra friction in its adoption. Microsoft can erase that friction with Web Services and then tackle the server-side (i.e. head-to-head competition with J2EE) as Phase 2 of its strategy.

Building software that matters

Industry gurus claiming that technology no longer matters to Corporate America may be drawing the wrong conclusion from the wrong evidence.

Just wanted to let everyone know that I wrote an article titled Building software that matters that was published on ZDNet today.

Pre-Integrated Airplanes

If the IT industry wants to be more like other, mature manufacturing industries, then large vendors need to be willing and able to integrate and resell software components as easily as they do hardware parts.

.NET on Linux, part 2 - "It's the API, stupid"

Speculation on a strategy for Microsoft to co-opt Linux

Pardon the title. I'm not actually calling anyone stupid. Just couldn't resist co-opting President Clinton's '92 campaign theme.

While writing my previous blog entry on .NET on Linux, I started thinking about what makes up an operating system. Certainly there is the kernel, there are system services, and there is the developer API. If one company is going to control the flow of money related to an OS, it may not need to control the whole OS. And if it set out to control just one part of the OS, the developer APIs would be that part. Controlling the developer API means controlling how software is built on that platform. It means being in the best position to provide tools for that API. It means being the one to arbitrate interoperability.

I believe that Microsoft has a shot, if they so choose, at making .NET a cross-platform developer API that would give them almost as much money-making ability and control over open-source OSes, such as Linux and FreeBSD, as they have over Windows itself.

A good description of the value of controlling the developer API is found in Jerry Kaplan’s book, Startup:

Creating an API is like trying to start a city on a tract of land that you own. First you try to persuade applications programmers to come and build their businesses on it. This attracts users, who want to live there because of all the wonderful services and shops the programmers have built. This in turn causes more programmers to want to rent space for their businesses, to be near the customers. When this process gathers momentum, it's impossible to stop.

Once your city is established, owning the API is like being the king of the city. The king gets to make the rules: collecting tolls for entering the city, setting the taxes that the programmers and users have to pay, and taking first dibs on any prime locations (by keeping some APIs confidential for personal use).

This is the great secret of the computer industry. While the newspapers chronicle the daily skirmishes of computer companies and their products, the real wars are over control of APIs, a subject too arcane to attract the attention of the press. But once an API is established, the owner has a natural monopoly of unprecedented proportions. API wars are brutal, winner-take-all conflicts in which the losers become mere shadows, eking out a marginal existence in specialty markets.

But it didn't work. Every pure Java office project, for instance, failed. Developers on those projects have told me that it was Java’s lack of focus on usability and performance that killed them. Those types of apps have to be pixel-perfect and Java was not pixel perfect. So Microsoft retained app supremacy and also retained control of the developer APIs on Windows, which has become essentially the only business desktop platform that matters at this point. Microsoft also performed an "embrace, extend, extinguish" on Java, almost immediately adding proprietary features to their version of the JVM, the result of which has been lawsuits, C#, and banishment of the JVM from Windows XP.

However, Java did go on to find big success on the server, where cross-platform does still matter (because there are still several vendors selling servers; if Microsoft sews up the server market too, then cross-platform won’t seem important on the back-end either). Plus, on the server, Java’s usability issues are far less of a problem.

To reconnect with my original point, I fear that Microsoft is maneuvering into a position to turn the tables on Java and provide what Java set out to provide in the first place: an abstraction layer that will allow developers to write to build high usability apps for many platforms at once. And it has a much stronger starting foundation: firm control of the most prevalent desktop platform, a reputation for getting things "pixel-perfect", and the world’s most popular desktop software, Office.

If Microsoft chooses to go down this route, it can jump-start the process and start making money from Linux and other OSS platforms by making its vast catalog of applications available for purchase on those platforms. Those apps will pull the .NET framework onto desktops that don’t already have it.

A world in which every computer is running Windows is probably impossible, because users get to choose, and there are users who don’t want Windows, for one reason or another. But only developers choose the API and write software to it. Users don’t necessarily even know about the API. If Microsoft successfully attracts large numbers of non-Windows developers to .NET as a way to develop Windows-style apps across all platforms, then they don’t have to wait for users to adopt Windows. The essential parts will be baked into everything they could possibly buy.

Of course Microsoft has to want to do this, which is not a given right now (although they are already testing the waters with the Mac and FreeBSD), and the success of this strategy will depend on how strongly Microsoft can establish .NET as the client side technology standard.

"I wonder when the Java developers will be as happy as the Mickeys"

What do you think about when you write Java?

I recently came across this blog entry, Java vs. .Net developers, in which the blogger, Steve Noel says:

"Mickeys [developers who use Microsoft technology] in general are very happy with the latest new tools thrown at them from Redmond, and very generalized also look slightly happier. Java developers on the other hand have a slightly more weary smile, and especially the open source-addicted ones like to make a lot of fuzz about Sun not doing justice to the great platform that Java is.

Technically, the differences in both software platforms are getting smaller every day. I wonder when the Java developers will be as happy as the Mickeys."

I was talking about the quote above with a guru-class developer friend of mine whom I respect totally and who has extremely deep experience with Microsoft technologies and Java. His immediate reaction, and explanation, was that when he uses Java, he finds himself thinking mostly about the technology itself. And when he uses Microsoft tools, he finds himself thinking mostly about the problem he is trying to solve. Somehow, he believes, Java distracts the developer with a sense of itself and its character, whereas Microsoft technology seems to blend into the environment, almost disappearing, and thus allowing the developer to concentrate more fully on the task at hand.

If this is true, this is a very powerful statement for Microsoft tools. Microsoft hopes to drive developer adoption of .NET by offering a superlative set of tools to make it extremely easy to create Web Services and user applications. Microsoft also offers a rich set of tools to migrate existing Java code to the .NET framework, a perfect “out” for Java developers who become enchanted with .NET. If Java cannot match this, it has yet another hurdle in its fight with .NET.

I have to give Java its due credit. When I used to code in C++, I had to think about memory management all the time. Now, thanks to Java, I don’t think about it any more. What a relief! Java has taken care of that issue for me, so that I can concentrate on my task at hand. Java needs to do much more of this type of complexity-hiding. I presume that this is the goal of Sun’s Project Rave.

.NET on Linux

Could Microsoft co-opt Linux?

I have read a number of articles and blog entries speculating about whether or not .NET will catch hold on Linux and on what it would mean if it did. Much of the speculation centers around whether Microsoft will put out its own version of .NET for Linux, but there is also a lot of discussion of Mono, Ximian’s version of .NET on Linux, which has been released without Microsoft’s participation and is gaining some traction.

Some of the commentators are concerned about the power that .NET on Linux will give to Microsoft, many others think that it would be a victory over Microsoft. To explore this, I’ve been considering the following “thought experiment”. Imagine this timeline:

1. Microsoft releases .NET framework for client and server.
2. Microsoft gets excellent traction with .NET on the client-side (which I firmly believe they will, unless they are more seriously challenged there, as I outline in my Java vs. .NET blog series)
3. Microsoft strongly encourages the adoption of Windows Servers by marketing the synergies between the client and server pieces of .NET, and makes some headway there
4. IBM, Sun, Oracle, and other Java vendors push hard to drive Linux adoption in the marketplace, at which they also make good headway. .NET starts to get some adoption on Linux thanks to Ximian Mono.
5. Then, suddenly, in the face of "customer demand", Microsoft "capitulates" and releases a version of the .NET server framework for Linux. It is not free but inexpensive, and perhaps nets them an amount of money approaching a basic OEM Windows Server license.
6. Microsoft then drives adoption the .NET server framework on Linux using the strong synergy with the large and growing base of .NET client applications, taking share away from Java app servers. Mono is crushed by Microsoft in the process.
7. Microsoft releases the .NET client framework for Linux and a version of Microsoft Office that runs on it.
8. Microsoft ends up owning the developer APIs for Linux, client and server, which is perhaps more important than owning the operating system itself.
9. Since no company owns the Linux kernel or the lower-level Linux APIs on which this .NET for Linux will be built, there is no one to thwart Microsoft’s efforts to control how software is developed on Linux. If Microsoft succeeds in taking control of the developer APIs for Linux, it makes money from Linux’s popularity, and once again there is no one to challenge Microsoft desktops.

Interestingly, Microsoft is already offering a portion of .NET for Mac OS X and FreeBSD. These might well be experiments to test the waters or perhaps simply ways to keep the DOJ calm. What if Microsoft helps BSD compete more effectively against Linux?

Java vs. .NET, part 5 - Rich thin clients

Let Java play to its strengths and co-opt Microsoft’s advantages

In the previous parts of this series on Java vs. Microsoft .NET, I lay out the threat that .NET poses to the Java ecosystem and the advantages on which Microsoft is relying to carry out that threat.

So…what is the response to this threat? Those of you who know me already know what I’m going to say: rich thin clients. In fact, a month ago java.net readers byronsebastian and d_bleyl forshadowed this entry.

The concept of rich thin client technology is to deliver the user experience of native locally-installed desktop software (co-opting Microsoft’s strength) from server-based applications (playing to Java’s strength). With this approach, Java gives developers a cross-platform method for delivering applications that feature the desktop benefits that users want with the deployment and administration benefits that CIOs are looking for.

I’m not talking about Java Applets, Flash, or other disguised fat-clients. In order to deliver on the full benefits of the server-based model, and to avoid walking into a Microsoft trap, rich thin client technologies must leave 100% of application code on the server. Putting code on the client means putting it in hostile territory where it can be attacked and thwarted by Microsoft. Additionally, rich thin clients need to be browser deliverable, but must also be able to operate independently of the browser.

It may, in fact, be necessary to use Microsoft’s own technology to implement the generic client-side piece of a successful rich thin client framework on Windows PCs/devices. I know that there is a feeling in the purist Java community that applications must be 100% pure Java to be acceptable, but I believe that the most important piece of the chain is that the applications themselves are written in Java -- that’s the part that builds a developer community. If those applications are then displayed by Microsoft technology on the desktop so that they can take advantage of all the desktop benefits, so be it. If Microsoft really does banish Java from the PC, it just won’t matter to rich thin client Java apps running safely on the server. On non-Windows desktops and devices, J2SE, J2ME, or even native technology can be used for the generic client. The desktop technology doesn’t matter -- in the rich thin client world, it’s invisible to the application.

I am also not talking about terminal server technology, like Citrix or X-Windows. Today’s rich thin clients can offer an immediate, responsive native desktop user experience, with no lagging “remote mouse” and with very high server scalability and super low bandwidth usage. They can offer the user experience that Microsoft promises with Smart Clients.

The Java platform must offer compelling benefits beyond simply matching Microsoft. Rich thin clients can do this:

• Write Once, Run Anywhere: I just read this article titled “Java Everywhere”, which stated “To get Java working properly on all devices, we must compromise one of Java's most recognized principles: Write Once, Run Anywhere (WORA).” How sad, and unnecessary. With rich thin client technology, a single Java code base can run on the server and project its UI onto a very wide variety of client platforms. WORA can be preserved.
  
  
• Open Standards: Move the entire balance of power to the server. Then open standards have some teeth.
  
  
• Security: Keeping all your code on the server means that your application cannot be a vector for viruses and destructive bugs to client PCs.
  
  
• Developer Productivity. Writing software that has 100% of its code on the server is easier to architect, debug, and manage than either client/server or multi-layer Web apps. Rich thin clients let developers architect their systems into as many layers as they want, not as many as the technology dictates. And it’s easy to bring standard, best-of-breed tools -- Java IDEs, debuggers, profilers, optimizers, etc., -- to bear on the entire code base.
  
  
• Resource-leveling: Utility computing promises to help companies save costs by virtualizing processor load and other resources across a managed grid. Keeping all the code on the server means all the code can benefit from this.

Rich thin client frameworks are also architecturally amenable to supporting a variety of languages. As I argued in the last part of this series, the Java platform needs to recognize the huge investment companies have in legacy systems and provide a way forward for those companies without requiring that they rewrite their apps in Java. Rich thin clients bring that legacy code into a server-based, network-centric environment and then give developers a way to add new features to those legacy apps in Java. Since all the code is on the server, it’s architecturally easy to deal with big piles of spaghetti (without having to disentangle them) and to mix and match languages and technologies, all under the covers and away from users and hard-to-manage desktop computers.

If rich thin client technology takes off, then it has the effect of marginalizing the desktop PC, a big strategic win for the Java camp. Rich thin client apps don’t generally care what kind of client hardware is displaying them. Customers can go with whatever is cheap and convenient, not with the platform that happens to support their favorite apps. This paves the way for non-Windows desktop proliferation.

I believe that our industry is shaping up for an epic battle between the Microsoft ecosystem, wielding .NET, and the non-Microsoft vendors, championing Java. The battle will be very hard fought and Microsoft will give no quarter. Already they have put Java into a difficult position. The best way out of the trap is not to fight them on their terms, but to redefine the battlefield. This opportunity is available because the world is moving towards being always connected. Microsoft realizes this and is trying to use our increasing connectedness as a way to drive their platform from the desktop to the server room. The Java world needs to head them off at the pass and make real the fear that Bill Gates had of the Internet in 1995.

Java vs. .NET, part 4 - Java is a language, .NET is not

Java takes a language-specific approach to solving problems, .NET takes a platform-specific one

One of the striking differences between Java and .NET is that Java is, fundamentally, a programming language and .NET is not. .NET is a framework that supports many languages. There has been a lot of identification of C# with .NET, but C# does not equal .NET, and you don’t need to use C# in order to build .NET applications. You can use one of the 20+ other programming languages currently supported by .NET. .NET’s view of the world is from the platform. It is designed from the ground up to leverage specific aspects of the Windows platform to its advantage.

Java, on the other hand, has a language-centric view of the world. Yes, with J2EE, Java has started to create a framework around itself, and extension technologies like Jini and JXTA certainly strengthen Java’s platform, but the way in which Java attacks problems is from a language point of view.

One immediate result of this difference is that it leaves Microsoft with the opportunity to surround Java with other languages. Not only does Microsoft already control the enormously popular Visual Basic and have the ability to make C# very popular, but it can appeal to companies that already have large code-bases in COBOL, C++, Smalltalk, Fortran, and other legacy languages. Java’s answer to those folks is: port your legacy apps to Java or use some kind of awkward connector bridge between the legacy code and Java. It is not natively tolerant of legacy code.

There have been attempts in the past to support other languages with the JVM. Eiffel can compile to Java bytecode. But those efforts have not gained any real support in the Java community. Bertrand Meyer, the creator of Eiffel, writes this in a paper describing his successful efforts to connect Eiffel to .NET:

This ability to mix languages offers great promise for the future of programming languages, as the practical advance of new language designs has been hindered by the library issue: Though you may have conceived the best language in the world, implemented an optimal compiler and provided brilliant tools, you still might not get the users you deserve because you can't match the wealth of reusable components that other languages are able to provide, merely because they've been around longer. Building bridges to these languages helps, but it's an endless effort if you have to do it separately for each one. In recent years, this library compatibility issue may have been the major impediment to the spread of new language ideas, regardless of their intrinsic value. Language interoperability can overturn this obstacle.
….
The language openness of .NET is a welcome relief after the years of incessant Java attempts at language hegemony. For far too long, the Sun camp has preached the One Language doctrine. The field of programming language design has a long, rich history, and there is no credible argument that the alpha and omega of programming, closing off any future evolution, was uttered in Silicon Valley in 1995. Microsoft's .NET breaks this lock.

Everyone will benefit, even the Java community: Now that there's competition again, new constructs are—surprise!—again being considered for Java; one hears noises, for example, about Sun finally introducing genericity sometime in the current millennium. Such are the virtues of openness and competition.

In summary, .NETs multi-language support is another threat to Java. Java needs to blunt this threat. Specifically:

• .NET will surround Java with alternative and legacy-compatible languages. The Java platform needs to become more language neutral while continuing to make Java the best language possible by dynamically incorporating new ideas such as Aspects and built-in support for Web Services.
  
  
• Java's language-specific solutions will isolate it. Make sure technologies mesh with no language assumptions (object layout, data types, calling conventions, runtime context, etc.)
  
  
• .NET as a platform has more hooks into the OS. Java needs to support desktop integration (icons, file linking), which is stuff that happens before any Java code gets run. This is client side, but it's all about what you can deliver end-to-end with Java application code.
  
  
• Deploying server-side J2EE applications is a bear. Java needs platform capabilities to make this much easier. The approach of offering wizards helps, but because they are glued on, they are brittle (hard to change after you’ve gone through the process once) and not compatible between different compilers.

(To be continued. And yes, I am about to offer some hope…)

The Internet Has Been Good to Microsoft Office

Standards, and corresponding monopolies, can occur naturally

Believe it or not, there are times when I feel some empathy for Microsoft. After all, I myself was once a small-time monopolist.

My first company, Astrogamma, had a product called FENICS that provided foreign exchange (FX) options pricing and risk management functions for traders. FX options are a particular kind of financial contract that banks and corporations trade as a way of taking bets on the fluctuations in the exchange rates between currencies or to protect themselves from those fluctuations (if you want a full primer in FX options, feel free to write me :) ).

The important thing for this discussion is that trading FX options turned out to be much, much easier if the traders on both sides of the transaction were using the same software. Our system caught on initially because of our focus on the user experience, our aggressive pricing, and the fact that we were able to seed our product into the brokerage houses (who were important market influencers) early on. But once we started to see widespread adoption of our software, the FX options market started to realize the benefits of having everyone use a standard system, which in turn drove further sales of our product until we had cornered over 80% of the global market of banks, brokerage houses, and large corporations that traded actively in FX options. We became, in effect, a monopoly. There was nothing nefarious about it. We didn’t set out to become a monopoly; we just wanted to create the best system on the market. We didn’t engage in any uncompetitive practices (we were actually a much smaller company than all of our competitors, starting out). It just happened that way.

This is an example of the network effect, where the network is of people trading on FENICS-calculated prices. The more people joined the network, the more valuable it became, and the more important it was for everyone else to join.

In discussing Microsoft, people like to point out their monopolies on desktop operating systems and Web browsers. But these are really by-products of their most interesting monopoly: Office. As David Kennedy pointed out this morning, Office is what drives the Microsoft desktop which in turn drives Internet Explorer.

A couple years ago, there was lots of speculation that Microsoft’s monopoly would be severely threatened by the Internet. Even Microsoft bought into this, which launched them into a furious and ultimately victorious battle to control the browser. The great irony is that, far from hurting Microsoft, the Internet has cemented its desktop domination. The further irony is that winning the browser war probably hasn’t helped Microsoft that much (except that it now allows them to keep Java off the client). The part of the Internet that helped Microsoft the most has been email. As email became more widespread, people began to email documents to one another (rather than printing and faxing or snail-mailing). This of course brought the network effect into full swing, and Office moved from being a “nice to have” (because of feature set) and an “easy to have” (because bundling arrangements Microsoft forged with PC makers) to a “must have” (because of file compatibility).

I doubt that Microsoft really set out to achieve this, but now it has happened, and I’m sure they are extremely thankful for it. Sun has made the strongest attempt yet at breaking the Microsoft Office hold by offering StarOffice, which has a high degree of file compatibility with MSOffice. It’s a bold strategy on Sun’s part, but so far has not really had widespread success. It will be very hard/impossible to compete effectively on Microsoft's own turf of the Windows desktop. Price doesn't seem to have been a big motivator for customers so far (StarOffice was free for a long time). StarOffice does help to make Linux desktops a little more realistic as an alternative to Windows, but really Windows and MSOffice now have such a strong symbiotic relationship that they are likely impervious to direct attack. The best strategy may be to try to change the rules of the game.

Java vs. .NET, part 3 - Open Standards

Java’s traditional weapon of choice

The concept of open standards has been the primary weapon of the non-Microsoft camp (which includes the Java community) against Microsoft. And it is a reasonable weapon. Open standards are meant to ensure interoperability between products from different vendors so that customers have the flexibility to put together best of breed solutions and, at least in theory, can swap out one vendor’s products for another’s if they become disenchanted with the first vendor on product quality or price. This means that all vendors are competing on a flatter playing field, and therefore customers and smaller vendors get the benefit of a more efficient market. Cliff Schmidt offers a very nice overview of the why, what, where, who, when, and how of standards.

Major vendors in the non-Microsoft camp push hard on the idea that Microsoft is proprietary and closed, meaning that Microsoft technology interoperates only with other Microsoft technology. A customer who goes down the Microsoft route is “locked in” and can’t choose to swap in non-Microsoft products.

The ideas behind the open standards movement are laudable, and I believe in them. Product standardization -- of electric outlets, of audio equipment connections, of bolt sizes, of fuel types, etc. -- has greatly benefited customers in general. It should certainly do the same in the world of software.

However, as a weapon against Microsoft, it has several weaknesses:

1. It only matters on the server. At this point in time, at least, Microsoft is the unrivalled king of the desktop. They set the standards there, and there are no major movements to challenge Microsoft as the standards-setter within that domain. This means that the concept of open standards in software really only has value in the server/network environment.



2. Microsoft developers don’t care. Microsoft shops are unswayed by the idea of open standards. For them, the standards that Microsoft sets are as legitimate as standards set by any official standards organization. It is a misrepresentation to say that Microsoft software only works with other Microsoft software. Microsoft has fostered a huge ecosystem of ISVs who conform to the standards that it sets. There is a belief in the Microsoft camp, justified or not, that software from vendors who conform to the Microsoft Standard interoperates at least as well, if not better than, software from vendors who conform to Open Standards.



3. The Open Standards camp is fractured. Standards are meant to foster cooperation, innovation, and customer choice. Unfortunately, in the melee of competition, large vendors are often guilty of using standards to club each other over the heads. They also use them, ironically, to keep smaller vendors out of the running by eliminating the possibility of innovation and reducing any competition to one of superior implementation of the given standard, which clearly favors large established vendors.



4. Microsoft is getting into the open standards game. Microsoft has been one of the loudest champions of open standards for XML and Web Services and has moved agressively to make C# an official standard. And they seem to be having a high time clubbing Sun over the head with various aspects of the Web Services standards process. Now, none of us believe that they truly believe in the philosophy of open standards, and there are even rumors that they will shortly abandon the official Web Services standards when they release Indigo. But in the meantime, their high visibility involvement in standards dulls the open standards arguments of the non-Microsoft camp.

(To be continued)

Blackout

Single points of failure can be entire systems. Prevention may lie in "fencing in".

For those of you on the West Coast, I can assure you that it was pretty dark here in New York last Thursday evening. A little after 4pm, suddenly all our lights, air-conditioners, phones, etc., in our office shut down. The UPS alarms started ringing, letting us know we were operating on battery power. We soon realized that the power was going to take a long time to come back on, hours if not days, and we didn’t have enough battery life for that, so all we could do was execute an orderly shut down of our servers and wait.

The effects of a loss of power are devastating, especially in an overcrowded city. No light, no A/C, thousands of people trapped in subways and on commuter railways, no ventilation in roadway tunnels, no ATMs, no credit card processing, no cell towers to relay our phone calls, no phone systems in our offices, no answering machines, no PCs, no refrigeration, very limited cooking, etc. Life as we know it completely on hold. We are utterly dependent on electricity and the systems that deliver it to us.

The power system -- something I admittedly don’t know a lot about -- seems pretty well distributed. There are a multitude of power plants, operating independently but interconnected through a singular power grid. This grid is supposed to be able to handle changes in local supply and demand, routing extra energy to a hot region where too many people are cooling off in front of the A/C, and seamlessly covering for a downed plant.

But apparently, these independent plants are also susceptible to each other, through the grid. I read that 21 major power plants spread out over 9,000 square miles all shut down within 3 minutes of each other, as a defensive response to some type of surge in the grid, leaving roughly 50 million people without power. Although the grid is supposed to nicely handle failures at any particular power plant, which I assume it does all the time and of which I am thankfully oblivious, it apparently can be a single point of failure itself, leading to catastrophic shut-down of the entire system.

So how can we prevent systems from being single points of failure? The answer may lie in the concept of "fencing in" instead of "fencing out". In my home state of Montana, the law of the land is "fence out". That means that it is incumbent upon any ranch to keep his neighbors’ livestock out of his fields – he is not responsible for keeping his own livestock in. This mechanism dates from the time when most of Montana was open range land, and the occasional farms were responsible for keeping that free-range livestock out of their fields. In this day, when all the land has been claimed and cut up into contiguous ranches, this "fence out" rule seems a little anachronistic, but it remains the rule.

I think that that same rule is used in numerous distributed systems. In our recent blackout, each power station acted entirely in its own self-interest and shut down to protect itself from the surge running across the grid, i.e. they each fenced the menace out. If instead, there were cooperation across the grid to isolate the surge, i.e. fence it in, then catastrophic system failure could have been avoided.

Currently viruses are handled by “fence out” methodology. Every individual system attempts to fence viruses out leaving the viruses free to run around the network looking for just one system that fails to fence them out so that they can propagate. If they were fenced in, they would not have the ability to look for a weak node to attack.

The only way to fence viruses in is to make sure that they have no medium for transmission. As we move towards a model of “utility computing” in which compute resources are served up like electricity from a distributed grid, the risks of a systemic failure become greater. However, since servers tend to operate in strictly managed environments, it should be easier to isolate destructive code (viruses and bugs) and its effects. And by connecting to desktop environments without sending executable content to them, we can make sure that destructive code never gets to leave that rigorously managed server grid. Mark Williamson at HP in the UK has been experimenting with using innovative "fence in" techniques to combat viruses.

It is consistent with game theory that the benefit of the whole is maximized by each constituent pursuing their own self-interest and cooperating to pursue the interest of the group. That is what fencing in requires.

XP, User Champions, and Software Vendors

Software vendors are in a better position than enterprises to have the full-time user champions that Extreme Programming requires

In his post, Fundamental Problem with Extreme Programming, Greg Vaughn argues that getting the level of business person involvement in software projects that XP demands is not realistic in practice. I have to agree with Greg's pessimistic view on how hard it is to get business people to set aside large chunks of their working time to help set requirements and provide a constant user feedback loop. However, I also fully agree with everyone who has responded to Greg's post by saying that without that involvement and feedback look, projects are likely to fail.

My own experience has been that for simple projects, this is not a huge problem - somehow the requirements get dragged from the business users and enough feedback iteration takes place to ensure that the project really does meet its requirements. This all happens far less efficiently than it optimally would, but if the project is small, that inefficiency doesn't add up to a lot of time in absolute terms.

But if the project is large and/or complex, a lot of focused user involvement is critical. The most successful projects that I have seen all had a user champion who felt that the successful completion of the software project would positively impact their own job performance, and so they are willing to sacrifice time spent doing their normal job in order to spend more time on the software project. Just as important as the time they spend is the focus of their attention. An effective user champion will be thinking about the project all the time, and will therefore bring better insights and more attention to detail to the project.

Finding a user champion can be difficult within a normal enterprise. It is rare that a company will assign a business user to be the full-time champion of a project. And even if they do, that user may not be fully engaged on the project (may see it as a distraction or as a tour of duty in the gulag). It is often a matter of luck for a successful project to find a willing champion who truly cares about the project and thinks that their career will be advanced by their involvement with it. And of course it is critical, but not always controllable, that that user champion know what he or she is doing.

This is a problem that software vendors can much more easily handle (if they choose to). One: since the developers of a package at a vendor tend to work for very long stretches on a particular piece of software, it is much easier for them to become fairly expert themselves in the underlying business that their software supports, which Greg states is the ideal (and I agree with him). Two: a vendor can hire professional user champions who will be dedicated full time to their software products. In my first company, which developed a package for currency options traders at banks, fully one third of our employees were former traders whom we had recruited to be those user champions. They walked the walk and talked the talk and they were all ours. The reason we chose the traders we did was that they had a fundamental interest in software, so much so that they were willing to leave their trading jobs to pursue a career in software. They were not necessarily the best traders, but they knew the business of trading inside-out and in time, with lots of practice, they became very adept at translating that business into software product requirements that our development team could work with. We called some of our ex-traders “Product Managers”, and they worked full-time on requirements specification and design testing. Others had different jobs in our company, mainly sales and customer support. All these activities kept them intensely involved with our product and the needs of our customers and thus allowed them to be effective participants in the product planning, design, and testing activities of our company.

Good professional services firms can have similar advantages. One: the development team may have had the opportunity to work on solutions for a particular business segment and thus built up expertise in that business. Two: good services firms become adept (since it is their main business) at drawing requirements from users efficiently.

So, in this respect, vendors generally have a better situation in which to attain the user involvement of XP successfully than enterprises. Because developing software is their main business, not a distraction from it, and because development costs are spread over fees paid by many customers, vendors are in a position to make the heavy investment in proper requirements gathering, design, user feedback, and QA that large complex software requires.

ASP.NET and Smart Clients

Microsoft makes money from Windows desktops, not from browsers

In response to the the latest installment of my Java vs. .Net series, a number of you responded with a focus on ASP.NET. ASP.NET is Microsoft's way of delivering browser-based DHTML applications.

Yes, ASP.NET is an important part of .NET, but I actually do not think that Microsoft is interested in promoting browser-based DHTML clients very heavily. Strategically, they need to continue to lock in Windows on the desktop, and fat clients are the strongest way to do that.

I believe that Microsoft's main strategic thrust will be around "Smart Clients". Smart Clients are .NET fat clients that rely on Web Services (served up by Windows Servers) and that can be trickeled to the client machine byte-by-byte (by Windows Servers), to make installation much more seamless to the end user. But they are still locally-installed Win32 applications.

Usability will be a primary driver for Microsoft to promote Smart Clients. Usability doesn't just mean the quality of the GUI or the richness of the controls (although those are very important). It also includes the ability to interact with other applications on the desktop (a big problem for browser-based apps) to provide an overall superior user experience (anyone remember the "Are you experienced?" campaign?).

Here is an excerpt from a newsletter that Microsoft sent around to ISVs this morning:

"ISVs: Get Ready to Deliver Smart Client Applications The Smart Client Readiness Program for ISVs gives you the software, tools, and technical resources you need to start building smart client applications. If your customers aren't asking for them yet, they will soon see the need for the next generation of anywhere, anytime data access. Enroll in the program today! http://go.microsoft.com/?linkid=215945"

Paradigm Shifts

Two articles recently got me thinking about the fact that paradigm shifts can be born out of convenience or necessity.

In his post, Another paradigm change is taking place right now..., Michael Nascimento Santos talks about the paradigm shift from Object-Oriented Programming (OOP) to Aspect-Oriented Programming (AOP) that he sees unfolding. AOP has very interesting features that may well advance the way we think about programming.

It got me thinking back to when I was first introduced to C++ and OOP. At the time, my team and I were all hard-core C programmers. We had already stumbled across the need for dynamic data binding and we so we used a lot of void* and function pointers, along with explicit type variables passed around in parallel to the data values, to simulate the effect you get with base classes and dynamic binding. We even implemented our own exception mechanism. That all seems pretty scary looking back on it now, but it actually worked very well in practice (don’t worry, I’m not recommending it).

When we were exposed to OOP via C++, our initial thinking was that C++ was simply a pre-processor on C that added some features that we had already implemented anyway in straight C, and that the main effect of C++ was to bloat and slow down our ripping fast code. And so we spurned it for a while.

But the industry moved forward and C++ became more widely adopted, and eventually we too started using it seriously. Once we did that, we quickly came to realize that the really interesting part of OOP is not in the specific mechanics of classes, inheritance, polymorphism, etc., but rather in the fact that it gives you a whole new way of thinking about software design and development. Once our minds had made the shift to the OOP way of thinking, there was no turning back. Today, it’s difficult for me to conceive of sitting down to write an application of any complexity using a non-OOP language. So the paradigm shift I experienced with C++ was much subtler but much more powerful than what I had initially imagined, and it took a while to sink in. This was a paradigm shift of ‘convenience’ – we could write software without OOP, but OOP gave us a better way to do it that opened up all sorts of possibilities.

There are also paradigm shifts of ‘necessity’. Water rising in a reservoir is going to experience a sudden paradigm shift when it starts overflowing the dam. The second article I read recently states that if China achieves the growth in individual personal wealth and standard of living that it projects to by 2020, the world’s natural resources would not be able to sustain it. For instance, if every person in China owned a car, the way that every American (on average) does, we would immediately exhaust the Earth’s supplies of metal and oil. If this is true, and accepting for the moment that China actually can reach that standard of living, then it’s clear that a major paradigm shift will have to take place. Either people in 2020 (in the US and Europe as well as in China) won’t have nearly as many cars as they do today, even if they have the same level of personal wealth, or we will have a completely different conception of what a car is. It will have to be something that does not consume metal and oil the way they do today.

So sometimes paradigm shifts take place because they provide excellent marginal benefits, sometimes they take place because there is no other way to address a looming problem.

Java vs. .NET, part 2 - The Nature of the Beast

What is Microsoft trying to do?

Microsoft is the uncontested champion of the desktop. In the business world, they own essentially the entire client-side market. This is a huge advantage for them. But it is also a limitation. In order to fuel its growth, Microsoft must find new, less-tapped-out markets to go after. The server room is one such market. Microsoft is already strong there, but they still have a lot of share to grow into, and it is a lucrative market.

In my previous post in this series, I claimed that Microsoft has the upper hand when it comes to the quality of the user experience. Microsoft’s user experience leadership is completely bound up with their domination of the desktop. It makes sense for Microsoft to use their hegemony on the desktop to their advantage. The client PC is their solid base, and .NET is the lever to get back to the target. .NET is an expansive strategy with many interlocking parts, and these parts come into play at various stages in Microsoft’s siege of the server room.

The UI layer of .NET is the tip of Microsoft’s spear. Microsoft leverages its usability advantage, combined with its very strong tools offering, to convince developers to adopt .NET as their platform for application development and deployment. .NET apps are delivered either as ASP.NET Web pages or as managed CLR fat clients. The thing is, in order to deploy and power .NET apps on the client or in the browser, you really need to install Windows servers, preferably Windows Server 2003 (formerly known as Windows .NET Server), in the server room. Ideally, you’ll also finally upgrade to XP on the desktops to boot!

From there, Microsoft uses the expansiveness of the .NET strategy to push out Oracle in favor of SQL Server and gets companies to install BizTalk and other Microsoft server technologies. The fact that so many companies already rely on Exchange for email helps in this. Microsoft will demonstrate the power and ease of using a pre-integrated stack from a single vendor to get customers to adopt more and more of their technology.

This is the threat that non-Microsoft vendors and the whole Java community faces. This plan is ambitious, but it is by no means easy, even for a company with the resources and advantages of Microsoft. Its success hinges largely on Microsoft’s ability to convince developers to adopt .NET. Therefore, the Java community’s challenge is to keep the tip of Microsoft’s spear from getting in by convincing developers and sys admins (and the companies that employ them) that Java has a more compelling answer for applications delivery than .NET.

(to be continued)

Docs >> Forms >> Apps

There is a natural evolution of platform technologies from document publishing to forms processing to application delivery. The Web is the leading example of this, but Adobe Acrobat PDF and Microsoft InfoPath are on their way.

The W3C has finally published its specification for XForms 1.0, after much delay and without the participation of Microsoft (not surprisingly). XForms is intended to make Web-based forms more usable by doing a better job of separating data values from form description and supporting cascading style sheets. The main benefit of these improvements is to make forms more reusable and easier to change and maintain with less re-coding.

There is an interesting evolution of platform technologies that start out as simple document publication frameworks (displaying read-only text and graphics to users), then, presumably under pressure from users, these platforms get extended to support forms (meaning that users can enter data which is then written back to a database on the server). The next logical step is to make these forms increasingly dynamic until they come to resemble full-fledged application delivery platforms.

This is exactly the evolution that the Web itself has undergone over the past 10 years. Most people agree that the Web does a fine job for publishing documents -- the truly revolutionary paradigm shift that the Web has delivered to date has been allowing all businesses to have universally accessible marketing materials on-line and to let anyone in the world do research through Google rather than the much, much more tedious means available before the Web. Web forms have allowed e-commerce to start to get a firm foothold. But Web technology is not as strong at forms processing as it is at doc publishing, as evidenced by the need for XForms at all. In the past few years, companies have tried hard to shoehorn full-blow applications into browsers using Web technologies, but these efforts have had very mixed results. Many vendors and standards groups have come out with a large stack of add-on technologies designed to patch up the problems that HTTP/HTML present for application developers. Other companies, like my own, have tried to rethink the application delivery problem from the ground up.

Now both Adobe and Microsoft are headed down the same road with the new forms-processing capabilities in Acrobat and XDocs/InfoPath. The question on everyone’s tongue now is how these products will compete with each other. A deeper question is how they will compete with HTML/XForms and whether they will indeed progress towards being full application delivery platforms.

It seems that there is market pressure for a platform to provide a continuum of capabilities from document publishing to application delivery. Maybe docs, forms, and apps are really all meant to be the same thing. But how we’ll achieve that is still far from clear.

Software Usability Case Study: Novices and Power Users

Yes, you can support both

In his post, Widgets follow form follows function, Chris Adamson ably describes the dilemma many software designers face when trying to design applications that support both novices and power users. In my post, Brittan’s Rules of Software Usability, I introduce the idea that software usability strategies can be seen through the application of three concepts: perspicuity, alignment to personal workflow, and style.

The dilemma that Chris describes stems from the fact that novices need more perspicuity (so they can figure out what to do) and power users care only about workflow efficiency (they already know all the functions by they just want to work fast). And this is a problem because perspicuity and workflow can interfere with each other in application design (wizards are an example of this).

But there does not have to be a conflict between perspicuity and workflow. I can’t resist offering up a case study from my own experience on an approach we took to support both novices and power users. My first company, Astrogamma, developed and sold single product called FENICS which performed pricing calculations and risk management analysis for foreign exchange options traders in large banks and brokerage houses. FENICS was able to capture 80%+ market share of institutional FX options traders around the world. We sold the company in 1995 but it continues its market domination today, in large part because of the quality of its user experience.

Traders are a very tough group to design software for. They are incredibly demanding. Speed of execution is critical for their business. They certainly have no patience to read a manual and learn how to use obtuse software. FX traders are very international (our customers were spread across dozens of countries) and many spoke very shaky English at best, so long explanations were lost on them. But traders also engage in a pretty narrow set of activities all day long, day after day, so they are prime candidates to become power users quickly. Our software was core to their ability to do their jobs, and most traders used only FENICS during their day.

In order to support a quick learning curve for impatient users, we used a fairly typical perspicuous GUI layout. All the fields were visible on the screen at once. All the functions were clearly labeled and visible at all time on a toolbar. The goal of our layout was to make sense of a trader’s world and present them with a full dashboard of fields and functions that would seem intuitive to them the first time they used our software.

So handling novices was pretty straightforward (we also had very complete but wildly underutilized documentation). But how did we handle power-users (the bulk of our user population) in that same interface? For that, we used a variety of strategies including the ones below, some of which admittedly took us a little astray from what is standard Windows GUI behavior today:

• Keyboard navigation: Mouse navigation in FENICS was totally optional and was in fact rarely used. All the data fields were arranged in two vertical columns, and the user could navigate from any field to any field with the arrow keys (more like spreadsheet cell navigation than a typical form) and we provided hot-key combinations to instantly move focus to any specific field. We also supported Tab which moved focus to the next empty field.



• Smart parsing: All data fields on the main screen were edit boxes. No radios or checkboxes on the main screen. And each of those edit boxes featured a smart parser that knew a lot about the type of data that was being entered into it. The parser would engage as soon as the user left the field or hit “Enter” in a field. We would try to interpret whatever the user typed in. Our parsers understand specialized lingo of FX options traders. We could parse dates in multiple formats, for a simple example. If there were ambiguity, the parser would pop up a list of choices for the trader to select among. If the user entered blank into a field, a list of all possible choices would pop up (obviously we didn’t do this for numeric fields!). The Esc key instantly dismissed the pop-up. As soon as input was parsed, it was immediately re-displayed into a standard format to let the user know that what they entered was understood.



• Use context: Not only did parsers know about the type of data being entered, but they also knew about the context. For instance, let’s say that at that time the exchange rate between Deutsche Marks and US Dollars was 1.5 Marks/Dollar and the exchange rate between Japanese Yen and US Dollars was 150 Yen / Dollar. If a trader entered “14” into an exchange rate field, then the parser would look at which pair of currencies had been specified for this options contract. If it was $-DM, then that 14 would be interpreted as “1.4000 DM/$” and if the currency pair was $-Yen, then that 14 would be interpreted as “140 Yen/$”.



• Multi-field parsing: In some areas we let the user enter values for several fields into a single field. They we would parse of the individual pieces and populate the correct fields with those pieces. This was extremely fast for the power user and a novice could always fill in the individual fields. So for instance, a power trader could enter “150 $ DM Dec Call” into the upper left field (which had focus when you first entered this main screen). This string of seeming gibberish is how an FX options trader naturally describes a contract anyway, so it was very natural, and it was translated as a “Call option to exchange US Dollars for Deutsche Marks in December at a strike price of 1.5000 DM/$”. We would parse all the pieces of that out and populate the individual fields: option type (call/put), each of the two currencies, the maturity, and the strike price.



• Auto-calculation: An option contract has many interlocking pieces of data, and specifying some number of pieces of data would necessarily imply what the remaining pieces would be. FENICS just did this automatically. For instance, there is a set relationship between the current exchange rate between two currencies, the interest rate of one currency, the interest rate of the other currency, and the ‘forward’ exchange rate of the currencies. As soon as any three of those four pieces of data are specified, the forth is calculable. So, in FENICS when any three of those fields was entered, the fourth was immediately automatically calculated and filled in.



• Default values: We tried to fill every field possible with an intelligent default, like today’s date or the most common market for a particular instrument. Some defaults were customizable by the user on a set-up page. Any default field could be overwritten on the main screen. If the overwriting value were erased, the default would reappear.



• Color coding: Using different font colors in the edit boxes, FENICS would show the user which fields had been filled in manually, which had been calculated, and which had default values in them.



• Get rid of things that interrupt flow: Everything vital to pricing an FX option took place on that main screen, and it was very ‘flat’. We featured no wizards, and used pop-up windows as sparingly as possible.

The main screen of this application was incredibly reactive. The user could move around the screen very rapidly, could enter values as they wanted to enter them, and the system was constantly interpreting what he user was doing to try to remove any unnecessary steps. These concepts proved so useful in FENICS that we carried them forward into subsequent products. They are even supported in our current product, Droplets.

To wrap up, this case study was intended to illustrate that there are ways that the seemingly conflicting usability needs of different types of users can be addressed at the same time, and to provide a description of what we did so that others can build on those ideas.

Why is my cell phone so much more powerful and easy to use than my desktop phone?

I have a big black phone with lots of buttons on my desk. I have a very small silver phone that I carry around with me all the times. I use each of these phones on a daily basis. Although they perform the same basic function (allow me to call other people and to receive calls), and they cost roughly the same, they are quite different in a number of ways.

Some of those differences make sense to me. For instance, I enjoy the comfort of the large form factor of my desktop phone. And of course my cell phone is tiny for easy portability. My desktop phone has some features that I don’t usually miss on my cell phone – multiple lines (my cell phone does have call waiting, but frankly I hate that), conference calling, intercom, and transferring calls – because I use my office phone for purposes that require those features and I use my cell phone for purposes that don’t generally require them.

However, there are some differences that make no sense to me. Specifically, my cell phone has a ton of great, easy-to-use features that my desktop phone does not have and that I wish it did. Beyond the obvious one that I can take my cell phone with me, these include a nice readable display and a totally useful built-in phone book (which actually should be server-based), it's compatible with any cheap ear piece (my desktop phone requires a $300 adaptor, unfathomably), I can see missed calls and recent calls (outgoing and incoming), it has voice-activated phone book and menus, caller-ID by default, ringer mute… The list goes on. It even has a bunch of cool features that I don’t use, such as Web browsing, email, games, and a built-in FM radio!

Now, maybe my desktop phone has a lot of these features, but if so, they sure aren’t obvious to me. And if I can’t use them, they might as well not exist. I am reminded of a Bjarne Stroustrup quote:

I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone.

I hope someone can explain to me why these gross differences exist. The only credible explanation I have heard so far (from my colleague Lou Franco) is that there is much more competition among cell phone makers and wireless service providers (who subsidize phone purchases) than there are among line phone makers and wired telephone service providers who, despite deregulation, represent near-monopolies. This competition has apparently led to a tremendous pace of innovation in the cell phone space.

So if my cell phone is so great, why don’t I just throw away my desktop phone? The main reason is signal quality. The difference in signal quality between my cell phone and my line phone is still great enough that I am unwilling to give up my line phone and in fact, I will prefer my line phone if both are available to me at any give point.

But, that signal quality difference is disappearing. Cell phones are getting better all the time. I hear that 3G will eliminate the difference. As that gap closes, I will be free to chuck my desktop phone, or, more likely, desktop phones will be forced to start innovating again to try to keep me from doing that. Already cell phone usage is surpassing residential landline usage .

There may be an analogy here for the software world. A number of people have said that Internet Explorer has been stunted in its innovation curve by the fact that it is a monopoly. During its fierce competition with Netscape, IE improved rapidly and became the better product, hands-down. But now that the browser war is over, Microsoft has no incentive to push IE's bounds: almost everyone already uses it and no one pays for it.

So what happens when an alternative becomes compelling enough for large numbers of people to use it rather than IE? John Patrick argues that Opera has achieved that. Joel Spolsky says that Mozilla Firebird is the one.

Line phones are still used, despite all the great features of cell phones because they have a ‘killer feature’ – signal quality. Does IE possess such a killer feature that will keep Opera and Mozilla at bay? Is it integration with the OS? And if so, then just as 3G promises to eliminate the signal quality difference, can IE’s killer feature be overcome?

Java vs. .NET, part 1 - Usability

Microsoft has the upper hand on the usability front

This Blog entry is the first in a series in which I plan to analyze the challenges that Microsoft .NET poses for Java and explore ideas for overcoming those challenges.

Many people love to rail against Microsoft products, saying how bad they are. And there is a sense in which this is justified: many Microsoft products are not as robust and scalable as some other products, and perhaps they don’t have all the conveniences for system administrators that other products do (at least they don’t in early versions).

But let’s face the hard facts, folks: Microsoft user applications rule. They are slick, they are sharp, they have tons of great features. Users like them -- overwhelmingly. Here is what one disgruntled CIO had to say about Microsoft product usability vs. that of the Linux community:

McCourtney added: "Microsoft is just more functional and useful. They actually conduct usability studies to see if people can intuitively use their apps. I don't recall any postings on SourceForge in that topic area." And if there are, I'll bet they say something like, "Users are dumb! They don't DESERVE to run Linux!!"

And it’s not just Microsoft applications. It is the Windows operating environment and all the ISVs who natively write to that environment. Microsoft sets the style and the ISVs (to one degree of success or another) follow that style, locking in the Microsoft leadership.

Please pardon me for saying this, but most Java apps look shabby compared with other desktop apps. Java now has a reputation for shabby-looking apps on the client-side. Swing was supposed to address this and has failed. IBM’s SWT comes closer but still hasn’t really challenged native MS technologies on the client. I am encouraged by Alan Williamson’s review of Juliette as a project that takes the UI seriously, but they apparently had to provide their own GUI layer!

There was hope a few years back that the Web would change this equation. The expectation was that all applications would move out of the native environment into the browser, where they would be much more intuitive than that complicated Microsoft stuff, and of course would be powered by server-side Java.

Well, although many apps have moved into the browser, usability issues haunt those Web apps – badly. Many Web app projects have become shelf-ware. The Web architecture has been sold to the CIO (and possibly CFO) as a way to reduce costs and increase flexibility; and the potential for that is real. But there has often been tremendous push-back from users on the sluggishness and low usability of those browser apps. For day-in-day-out usage, users generally prefer the experience of their old client/server or desktop applications. Amy Fowler gives a great example of this for the consumer market. (And by the way, who controls the browser?)

The non-Microsoft camp likes to claim that MSOffice is so popular simply because it is often bundled with new PCs, and there is no doubt that plays a role. But it is also the case that Office and other Microsoft-based apps are very sharp and highly usable for the vast majority of users. We must take product usability very seriously to make inroads against Microsoft domination.

This work is licensed under a Creative Commons License.