I just got done writing the editor's note for VSLive! Orlando (I'm the conference chair for VBITS and VSLive!), which helped clarify in my own mind something that I observed last week while doing a couple of INETA user group presentations.
First, for Julia's group in Burlington Vermont where I did a presentation on "Architecture and Design for .NET", I was struck by the modest scale of the applications being built there. No 100-person IT departments: In fact, it seemed that many of the members were the entire IT department in their organization! And these weren't just mom & pop operations, but real industrial / distribution / retailing businesses. Mixed in with were a few CS types, including at least one university CS professor, but the feeling I came away with was of people who needed to get a lot done with very little in the way of resources. They were as excited about SharePoint as they were about VS.NET because it was that much more functionality they could leverage.
And in Boston, where Chris Pels allowed me to present on "Resources and Globalization for .NET", the clear majority of the members - at least at that particular meeting - were working on rich / smart / Windows client development, mostly using VB. Lots of larger enterprises represented in industries like finance and insurance. So, while these guys have a bit more to work with in terms of resources, they too were mostly interested in getting their jobs done. Coming after my talk, Jeff Richter - an acknowledged wizard of .NET's internal workings - reprised a talk he did at TechEd that highlighted a few of his favorite technical topics including code obfuscation, native image generation, and theoretical performance improvements of managed code.Talking to the members afterwards, all I heard was "yeah, that stuff was interesting but it's not anything I can use like your system for automating resource builds". Of course, that's what you expect people to say (you never hear directly that your talk wasn't anything but great) but the point that it illustrated for me is that there are people who like technical stuff for its own sake, and those who are mostly interested in applying the technology to build a solution.
In the past, this was a much clearer distinction. C and C++ developers built the Windows platform and libraries of reusable components, but it wasn't until the VB developer - drawn in many cases from the end-user ranks - built solutions that the Windows platform really took off. These two types of developers were at different ends of a spectrum anchored by the business process on one end, and something close to computer science on the other end.
With .NET, the picture has been substantially clouded. Developers are told to pick whichever language they feel more comfortable with, but then all sorts of caveats - some real, some imagined - pop up. And are debated endlessly. With the launching of .NET, the obvious focus has been on the lower-level platform functionality. And so the developers at the business end of the spectrum - who have seen a substantial shrinking of their world - have geared up to move further down the chain towards the platform developer. It isn't so much the language, but rather what they _do_ with the language that distinguishes platform developers. They would rather write an elegant, reusable class library than do almost anything else, particularly interact with users. But people used to building solutions are perceiving that the only way they'll be able to stay competitive in the IT industry is by becoming more technical. In effect, we are marginalizing out those who would rather talk to users in favor of those who would rather talk to the platform.
What seems clear to me, though, is that any particular developer can't optimize for both ends of the spectrum at the same time. What's has been sacrificed so far is the focus on the end-user's needs. Microsoft has talked about re-enabling RAD - and has indicated that the emphasis will be on VB - yet C# developers seem to believe that they'll get all the RAD stuff as well. Can that really be true? Can Microsoft really optimize a programming language & toolset for both solutions builders and platform builders? In my opinion, VB developers transitioning to C# are betting the answer to that question is "yes". And I don't think that - in the long run - that is going to be a good bet to make, particularly if your strength lies in building end-user solutions.