PROGRAMMING WITHOUT A .NET

By Tamara L. Cravit

Microsoft’s .NET initiative is huge. If one doubts that, one need only read Bertrand Meyer’s series of articles in this and other issues of Silicon 2.0.

The question isn’t whether .NET is here to stay. Microsoft doesn’t routinely spend $2 billion on nothing. The question is whether .NET is really going to change the landscape for software and Web developers. My view, based on more than a decade as a software developer: wait and see.

.NET is not the first technology that has promised to revolutionize software development. Sun made similar promises with the release of its Java technology in 1996. Java’s promise was “write once, run anywhere”—a sweeping vision of cross-platform compatibility and interoperability. More than five years later, Sun still has not really delivered on that promise.

As a software developer, I watched the evolution of Java with interest. The original release of Sun’s Java tools was provocative and useful, but did not deliver on Sun’s overarching vision. Now, six years later, I can run Java applications on my PalmPilot. I can write Java code that will—more or less—run with little modification on Windows and Macintosh systems.

Has Sun delivered a useful tool? Absolutely. Has it forever changed the face of software development? I don’t think so.

Microsoft is facing a tough road if it plans to radically alter how software development is done. Many individuals and companies are used to the way things work now and are resistant to change. Nowhere is this more clearly seen than in the discussion of proposed language changes in Visual Basic.

In the first Visual Studio .NET beta, Microsoft made several low-level changes to the Visual Basic language, used by an estimated 3.5 million software developers. These changes made good sense and were intended to reduce errors when combining Visual Basic source code with source code from other languages.

Bowing to pressure from the development community, Microsoft has removed these changes from the forthcoming beta 2 release. Microsoft decided that making all its development languages work together was less important than keeping legions of developers who were used to a certain way of doing things happy. In this climate, it’s hard to see how Microsoft’s “new vision” is going to win the developer support needed to carry it.

It’s not easy even for those of us who want to join the .NET bandwagon to do so. When the first version of the .NET toolkit (known as the “PDC Preview” version) became available, I decided to take a look. I downloaded and installed the 60MB file, and wrote a simple application.

Because Microsoft is still refining the tools and interfaces, my test application won’t work with the newer beta 1 release of .NET. If I want to use my test application with beta 1, I’m faced with rewriting about 20 percent of it to conform to the newer tools.

This constant state of change makes it unattractive for those developers who wish to test .NET by writing real-world applications with it. As a software developer, I cannot recommend to my clients that they develop software solutions whose source code will be obsolete in three or six months. I cannot justify spending the time to learn a set of tools and procedures, which will be obsolete as soon as I’ve learned them. I cannot even justify evaluating .NET again until it’s a stable, shipping product.

Adopting .NET is not just a technical decision, either. Microsoft’s Hailstorm initiative, recently unveiled as a key component of .NET, raises serious concerns as well. Hailstorm aims to provide a variety of common functions for application developers—such as user authentication and registration—in the form of reusable, off-the-shelf components. This would, in theory, enable a Web developer to shorten development time by removing the burden of developing this common core of functionality. Sounds good, right?

In practice, this is problematic from a privacy and security standpoint. The underpinning of this whole new set of components is a Microsoft technology called Passport. Microsoft already uses Passport for connections to its Hotmail service, as well as on other Microsoft and third-party Web sites.

Microsoft has announced plans to integrate Passport technology into Windows XP, which is currently in beta testing. Microsoft’s vision is that any Web site could tie into Passport for user authentication, as well as to obtain user addresses, credit card numbers and so forth.

In theory, this is a good idea. In practice, I am uncomfortable with the ramifications of this vision. For one thing, the Passport database, which lives on a Microsoft server, is a highly attractive target for hackers. If the Passport database were compromised, site accounts, credit card information, and even computer and e-mail logins and passwords would be vulnerable.

Alternately, someone who compromises the security of my laptop today cannot gain my credit card number. Under Microsoft’s new vision, my credit cards would be at risk.

In concept, the ideas which .NET embraces—reusable components, consistent software architecture and a greater ability to meld software applications to the Internet—are laudable ones. The .NET initiative is not the first, and I suspect, not the last, effort to bring these goals to market.

Whether or not Microsoft will be successful in selling its vision, and in delivering on that vision, remains to be seen. Until there’s more substance behind the .NET hype, it will remain just that—hype.

Tamara L. Cravit is a partner of Taylored Software, a Buellton firm providing custom Web and business software development services. She can be reached by e-mail at tcravit@taylored-software.com, or on the Web at http://www.taylored-software.com/.