Phoenix DevDays


Yesterday was DevDays here in Phoenix. It was OK. Nothing special. It’s the first time I’d been to DevDays so I wasn’t sure what to expect. Almost all of the speakers were community volunteers and surprisingly good. It made me wonder though what DevDays would be like if it were a community event where Microsoft simply was a sponsor.

Oh, and if anyone was wondering why Whidbey isn’t shipping soon–you should have been at the Phoenix DevDays. The demo flopped. It was a demoer’s nightmare. At least he had a sense of humor about it. The presenter was wondering if part of the problem was with Virtual PC. He said he’d bumped the memory allowed from 256 to 512 MB before the keynote because Whidbey had been running so slow. Virtual PC was definitely like a ball and chain around the UI. It sure slows things down–which is especially bad for non-optimized, pre-alpha code. I’d suggest a dedicated box next time. Virtual PC is cool–but in key demos it adds one more thing to go wrong. And is it really necessary?

Also of note, the message gets a bit confused sometimes with the future of C++. Is it a first class language or not? I listened to a Microsoft Longhorn webcast the other day and the message was an emphatic yes. However, at a more corporate/IT-oriented event, like DevDays, C++ takes on some jabs.

Similarly, I recall last year at the Server 2003/Visual Studio launch the local Microsoft evangelists were spouting figures as to how much more money C# and VB programmers are paid than C++ developers. And that all smart developers would switch. This time around the message in the keynote was that C++ programming is going the way of DOS development. Interesting.

Now some of the message I think is getting muddled by Microsoft’s attempt to convince developers to stay away from COM. Makes sense–especially in light of .NET. But why throw in C++, I don’t get it.

The style of development that I know, which leverages layers of abstraction where lower layers are built for speed and durability and built in a more flexible style is all but gone in the Microsoft messages. Instead the message is: .NET subsumes everything. So you’re done. Hmm. That’s not the way I’d engineer it. I think it’s because I enjoy creating product-style applications whereas much of the emphasis today is on consulting and one-of in house projects (which no doubt make up the majority of development efforts.) As a product-oriented engineer I wonder if the message is simply one of targeting a group which I’m only partially part of or is it that Microsoft is pursuing a technical direction that the engineering side of me is uneasy with? It took Microsoft a long time to come around on COM. Let’s hope that the same thing isn’t happening with how best to leverage .NET.

It’s interesting about Longhorn. As an engineer I understand reworking the Windows code–collapsing old hierarchies, removing dead code, improving APIs, eliminating redundancies, setting the road for future customer needs, making the code more robust and improving performance along the way. This is all OK. But then I hear discussions of the framework being everywhere. And then I begin to get a bit concerned. I wouldn’t do it that way–unless I knew very well what the “framework” was. Actually, my engineering nose smells marketing. I think some concepts are getting collapsed down–not simply on the engineering side–but on the marketing side. I can’t wait to see how it all works out.