It’s clear that developers and systems analysts are excited about Microsoft’s .NET. When I recently polled 1,500 attendees at two regional developer events, nearly everyone was using some sort of Microsoft development technology, and 85 percent indicated they’re eager to write new applications or upgrade to .NET next year.
But when I inquired about how many were ready to start converting today, less than 10 percent raised their hands. During some later Q&A sessions, I asked them to share what would be necessary for them to use .NET technologies.
In this article, I'll discuss the first two of the four top requirements developers said needed to be fulfilled before they would be ready to convert to .NET. I'll talk about the last two requirements in my next column.
Step 1: Education on key technologies
One of the first things any developer will tell you is that he or she needs more training. This is certainly the case with any new technology based on relatively new protocols like XML and SOAP, and this has never been truer than it is for .NET.
Since .NET is built from the ground up to support Internet protocols, it will be crucial for developers who’ve not been immersed in these technologies—probably 98 percent of today’s developers—to get additional training. This could be through books or seminars at first, but ultimately, the best source will be instructor-led training.
Microsoft recognized these educational needs and launched a series of national .NET developer seminars that took place in September and October of 2001. If you missed the first round, talk to a Microsoft account representative, a local certified training and education center (CTEC), or the Microsoft district office about hosting a seminar in-house or attending one at a local CTEC. Each district offers dedicated Microsoft .NET evangelists who can schedule classes.
Be aware that these two-day .NET seminars expose developers to the breadth of new technologies at the expense of significant depth in any one technology. Developers will leave with a foundation of knowledge that should be strong enough to prepare them to continue their training, either with a personal instructor or by using additional educational materials from popular .NET Web sites, including MSDN, GotDotNet, and 4GuysFromRolla.com.
Step 2: Direction needed on preferred languages
One of the great things about application development and the .NET Framework is that you can use any language. One of the most frustrating things, however, is that you have to choose the language.
This frustration centers on two key issues. The first is whether or not a Java developer can write code that will execute on the .NET platform. The answer is yes—sort of. Microsoft has introduced an upgrade to its J++ technology that replaces the (allegedly) Java standard J++ language with a new language for the .NET platform called J#.
J# is Java compatible, meaning that if you write Java code using J++, it’s likely to work in the .NET environment. Microsoft has added some special classes to the environment that allow Java programmers to use the .NET Framework without having to rewrite their code. The J# technology is in beta now and will be fulfilled by a coupon in the box shortly after the core Visual Studio.NET product ships (in early 2002).
It’s important to point out that writing applications for J# only means that the applications will run on the .NET runtime. Microsoft doesn’t intend for J# code to be portable to non-Microsoft environments.
If your shop is developing both Java and Microsoft language-based applications, you should take a look at the .NET Pet Shop application available at GotDotNet.com. To demonstrate the advantages of the .NET platform, Microsoft ported Sun’s J2EE Blueprint application to a .NET environment. .NET Pet Shop implements the same functionality as the Sun Java Petstore application in one-sixth of the code, supporting six times the number of concurrent users while also increasing performance by 2,800 percent. Using standard framework classes, they also added enhanced functionality, including mobile device support and XML Web services. This is a great example of how the .NET Framework lets developers create robust applications by using the power of the Framework independent of the language selected.
This, ironically, leads to the second key language issue. Should an existing Visual Basic developer move to VB.NET or switch to C#? This is where you need to do some real work to determine staff capabilities. Visual Basic developers, in general, fall into two camps: ones that embraced objects and classes, and ones that didn’t.
Those who embraced objects and classes were also the ones who learned about calling those objects from ASP applications. Unfortunately, it’s not as simple as asking people what version of Visual Basic they’re running. Most developers I’ve worked with on new projects already have the latest versions of the tool. But I’ve seen literally hundreds of VB programmers who write VB3 applications (before classes) using the VB6 environment.
Assuming you’re comfortable with a mixed-language shop, my core recommendation is that you take developers who haven’t mastered objects and classes and move them to C#. I believe they will be better developers if they learn how to write OOP applications while learning a new language, rather than being distracted by what they already allegedly know about VB syntax. If they were going to be object developers in Visual Basic, then they would already have moved to it by now.
Next week, we’ll look at the other two issues developers believe must be dealt with before they can move to .NET.
Are you ready for .NET?
If not, what obstacles are you facing? E-mail us about them.