Developers

The biggest impact of .NET is on software developers. They get new architectural options, simplified development, and hopefully more robust software. They also get a wider range of programming models to use.

A Spectrum of Programming Models

In existing Microsoft-based development tools, there are a couple of quantum leaps required to move from simple to complex. And sometimes the complex programming models are required to get more power. A developer can start simply with Active Server Pages, but when those become cumbersome, it's a big leap to learn component-based, three-tier development in Visual Basic. And it's another quantum leap to become proficient in C++, ATL, and related technologies for system-level work.

A key benefit of .NET is that there exists a more gradual transition in programming models from simple to powerful. ASP.NET Pages are more structured than traditional ASP pages, and provide on-the-fly compilation to get better performance. Visual Basic becomes a tool with wider applicability, as it becomes easy to build a web interface with Web Forms, and it also becomes possible to use advanced object - oriented designs. System level capabilities become more approachable with C#, and even C++ becomes more practical with managed code taking away a lot of the tedium.

This increases the odds that a developer will be able to settle in at the right balance of power vs. simplicity. When a developer's current programming model starts coming up short, there will be an option to get more power that doesn't require a radical readjustment.

Libraries of Pre-written Functionality

The evolution of Windows development languages has been in the direction of providing more and more built-in functionality so that developers can ignore the foundations and concentrate on solving business problems. .NET continues this trend.

One particularly important implication is that .NET extends the trend of developers spending less time writing code and more time discovering how to do something with pre-written functionality. Mainframe COBOL programmers could learn everything they ever needed to know about COBOL in a year or two, and very seldom need to consult reference materials after that. In contrast, today's developers spend a significant portion of their time digging through reference material to figure out how to do something that they may never do again. The sheer expanse of functionality available, plus the rapidly changing pace, make it a requirement that an effective developer also be a researcher. .NET accelerates this trend, and will probably increase the ratio of research time to coding time for a typical developer.

Infrastructure Engineers

A major design goal in .NET is to simplify the lives of folks who install and care for computing infrastructure. By alleviating "DLL Hell" and many other deployment problems, infrastructure workers should find themselves relieved of many of the most frustrating and tedious aspects of Microsoft platform deployment.

On the other hand, with applications becoming more distributed through web services, the need for reliable connections both within organizations and through out the Internet will increase. The responsibility for that will certainly fall on the infrastructure technicians.

End Users

Any new computing platform must ultimately benefit the end users, or else it's not of much value. .NET clearly does that, since once the .NET framework is on an end-user's system, adding new applications should be easier than ever before. Meaning that they should run into fewer technical glitches that require expert assistance.

More importantly, they will have access to new Web-enabled applications that have the potential to reach ever-higher levels of functionality and productivity. They will have applications that draw together information and processing services from all over the globe, and integrate them into an easy-to-use, customized form.

Cautions

No one knows for sure if .NET will live up to its billing. Many of us were surprised at PDC to see how far Microsoft had progressed with this very ambitious effort, but there remains a lot to be done. We are even more optimistic after seeing the stability and completeness of beta one for Visual Studio.NET. But it's important to recognize that building-in the intelligence that will be required for .NET to work is a huge undertaking, and there are risks that some pieces of it might take another generation or two to be truly ready for prime time.

There is also lots of uncertainty as to the time frames that will be required before the first .NET technology rolls into production status. In the meantime, it's important to understand enough about .NET to know when it makes sense to look seriously at using it, and to orient our current development practices in ways that will make eventual migration to .NET simpler and faster.