re: Overheard in the halls on the hill above Redmond:
Fortunately you wrote "1 April" on the bottom line... GREAT JOKE! :-)
« February 2005 | Main | April 2005 »
-30-
1 April, 2005
I just got back from the Developer Connections conference in
When I visited the speaker’s lounge I felt like a caged bear with kids poking me with sharp sticks. It seems that the Microsoft folks in attendance took exception to the Visual Basic 6.0 petition that I signed along with a number of other MVPs. A couple implied that I would be lucky to keep my MVP status because I chose to speak up. Sadly, I think these Microsoft folks just don’t get it. When Microsoft decided (quite some time ago) to “drop support” for Visual Basic 6.0 I don’t think they realized the impact this would have on the companies that used Visual Basic to create commercial applications. Let me put it this way:
Sam starts his day by cruising the internet—he’s looking for new car as his 78 Dodge Dart is getting hard to start—not to mention the smell of dead cat in the backseat. Liking the looks and features of the new Ynhoi, he does a bit of research and discovers that the car uses well-respected and well-understood technology. It’s visually a bit basic on the looks side, but it’s easy to maintain and he knows lots of places where he can get it serviced. Ah, but then he discovers that the engine is built by another large well-respected company—but that company has decided to drop its support in favor of the new hydrogen powercell engine. On top of that, it seems this company supplies engines for most of the cars he’s interested in buying—at least the ones he can afford. He read that the dealer can pay extra for support, but the engine company has already moved its engineers on to perfect the new hydrogen technology.
Sam’s not sure what that means, but he doesn’t want to get stuck with a car that he can’t get serviced a few years from now. He reads all about how the new technology is very cool but wonders if he’ll need a special refueling station or some special changes in his garage framework--he's just not sure. He wonders if it would be foolhardy to choose a car based on apparently dated technology. He doesn’t want to have to convince his wife (who watches the budget like a hawk) that he should buy this new car that has an engine that won’t be around that much longer. He decides to talk to the dealer anyway. The salesman assures him that the car does everything he needs and more and that they intend to support it for years to come. They say that the engine is very reliable as they have had more than ten years to perfect it and match it to the latest XP transmission. “But what if something goes wrong with the engine in a few years, say in 2008? Will you still be able to get parts?” The dealer turns a bit red, and shuffles as he does not know the answer to this question—one that he’s been getting a lot lately. He knows his own company is years away from creating a hydrogen powercell model and he’s not really sure he’ll be in business in 2008.
Sam decides to wait on buying a new car for awhile. He wants to see how the new hydrogen engines hold up under real driving conditions and until there are more people out there that can service them. Who knows, perhaps by the time he’s ready to buy, the technology might have changed again. He remembers hearing about that new Longhorn transmission but he’s not seen any of the new hydrogen engines work with it. When Sam calls the dealer a week later to ask another question he finds they’ve closed their doors as have some of the other car dealers in town. He feels lucky that he didn’t buy that car after all—and then his old clunker starts to make that noise again.
I think it's too bad Microsoft can’t take back their decision to stop support—the dye is cast. It’s probably too late for the tens of thousands of software vendors who sell Visual Basic 6.0-based applications as many of these companies can’t afford to retool—not in these hard times--even if they knew how. I expect that it will take some pretty serious back-peddling and fence mending to get the market to trust Visual Basic again—in any form.
We had a chat this morning with Eric Rudder. He gave us a few promises regarding the future of the Visual Basic 6.0 runtime. I don’t know how many folks from the development team are considering switching to the Halo group after this… Oh, another interesting point. For the first time, we were attacked by several spammers. Thankfully the moderator was able to get them off, but geeze, cant’ we get anything done in this industry without these mindless twits disrupting people trying to carry on a conversation?
Not long there after, I was asked by a member of the press to comment on the public chat this morning with Eric Rudder. This is how I responded:
Let me start by saying that I think that Microsoft is really interested in the welfare of the developer community. If they were truly arrogant as some would have you believe, they would not open themselves up for comment and shield people like Eric Rudder from the outside world. However, as I see it, they’re between
It’s hard to put a finger on what a Visual Basic developer really is. It’s not like C++ that requires a degree in abstract thinking to understand. Consider that Visual Basic in its many forms is easy enough for virtually anyone to use—regardless of the consequences or the skill level. In the hands of some developers I see Visual Basic as a poor-man’s
When Microsoft introduced Visual Basic .NET they assumed that once the “new and improved” language hit the streets that the hordes of developers would adopt it. They didn’t. This new language they called “Visual Basic” .NET was different enough that many of the paradevelopers and the pros didn’t want to invest in the new version. The other problem was that in the early days Microsoft kept saying that .NET was all about Web Services and ASP development. Not everyone (by far) was building web sites and they had no idea how a web service could help them. This put a damper on the momentum to migrate as much as the sour economy. Lots of companies simply didn’t (and still don’t) have the money to invest in yet another new technology. They think that as long as their old gas-guzzler is still running, they can afford to pay a bit more for gas—as long as their application is still working, they don’t see the need to convert. They figure that they should wait until Longhorn anyway—it’s just another few months away (or so they think). When it comes they’ll reevaluate the impact and whether or not it makes sense to migrate. Who knows, by then there might be yet another technology entirely different from .NET and they will save money by skipping this wave.
What should Microsoft do? Perhaps if Microsoft had named the new language something else (like “Visual Fred” or “B#”), they could have kept Visual Basic alive and made the transition smoother for their customers—but that’s water under the bridge. I don’t see Microsoft doing much more with Visual Basic 6.0. They simply don’t have the resources to do both. However, I think they need to focus on what’s best for Visual Basic 6.0 developers—the people they convinced that this was the best long-term solution for their application requirements. I think this means keeping the product alive by making sure it works in XP, Longhorn and beyond. This means keeping their staff working on bug fixes and compatibility issues as these new platforms evolve. I think we heard today in the chat that Eric has committed to this. I would like to hear this from Bill (the other one). Remember when Steve said “OS/2 OS/2 OS/2”? I would like to see continued support for Visual Basic 6.0. They have agreed to provide this (for a fee) but does this mean they pass this off to people overseas that don’t know the product?
I also think that Microsoft needs to take a hard look at the disruption they’ve caused in the industry as they constantly churn the technology. They can’t expect to reinvent the wheel every five years or so and expect the world to adopt the new technology just because it’s new and improved.
I tripped across a problem that I hope is just a bug. When I opened a connection with a bad server name I got a timeout (number -2). I expected a "SQL Server not found or..." exception (17) because that's what we've been getting since the dawn of time with ADO classic and ADO.NET 1.0 and 1.1.
Dim Cn as New SQLConnection
Cn.Open()
For those that can't read Visual Basic .NET...
Data.SqlClient.SqlConnection Cn = New SqlConnection("Server=fred;Integrated Security=SSPI;");
Cn.Open();
These throw a timeout (-2) exception--not a SqlException 17.
I'm testing the FebCTP Visual Studio 2005 with SQL Server 2005 in the same VPC.
Incidentelly, we now know why ADO.NET 2.0 is behaving like this. I can't reveal the reason (NDA), but I'm on top of the issue. I'll post something once we figure out what to do. Stay tuned.
March 4, 2005 • Vol.27 Issue 9
Page(s) 21 in print issue
My Microsoft wireless router now paperweight went south for the winter. Because its range was about as far as I could throw it in the living room, I decided to upgrade to a router-bridge rig that could get me better connectivity. My house is pretty ordinary by U.S. standards—wood frame and not much that would block the 2.5GHz signal. I had already switched away from my Siemens 2.5GHz two-line phone system because it (according to Siemens) "used up" the entire band (and then some). I replaced it with a Uniden 5.8GHz phone that theoretically wouldn't fight as much with the wireless 802.11 network.
I had a tough time finding a suitable wireless access point and repeater that would work together, even after researching. Most of the rigs warned that they only bridge between their own proprietary units and are not compatible with other brands. The other factor I considered was past experience with the company and its support team. While I'm not exactly a village idiot when it comes to installing hardware, sometimes I need a bit of help working out the kinks. As you know, I'm also partial to people that don't read scripts and speak in gerunds to answer my questions.
Installing The Buffalo G54
While browsing at CompUSA, I stumbled upon a Buffalo G54 AirStation and Repeater kit. This wireless router and separate (very small) repeater are designed and preprogrammed to intercommunicate to permit a much wider 802.11 coverage area. The price was right (about $125), so I asked around and found it was little known but pretty well respected. I was warned that setup was tough but support was good. It was also touted to have excellent range. I'd be happy to be able to span the house (about a 120-foot radius), so this seemed like a good deal.
The G54 was hard to set up. (Ominously) the problems started with the documentation; apparently, it's in Chenglanish. You know, English translated from Danish translated from Chinese. When you connect to the units via HTTP, the text for some of the dialogs was almost comical. Yes, the G54 had every option imaginable: three different types of security and the ability to set every possible 802.11 option you ever heard of (and probably several you haven't). The next problem was figuring out how to deactivate many of the features. Sure, I wanted WEP security and MAC filtering, but I didn't need the DHCP functionality or the myriad other security and configuration features. By the time I got done tinkering, I couldn't connect, but I did get it to flash the LEDs like a Christmas tree.
How Customer Support Sites Can Be Run
In desperation, I called the Buffalo Tech 24/7 support line and almost immediately was connected with an intelligent-sounding gentleman who (in American English) patiently walked me through the configuration. (He must have been on Valium.) What was especially nice is that he adapted his instructions to my skill level. Instead of saying, "Press the Green Start button with your left mouse button; now click Run and type cmd," he said, "Start a command prompt."
He was very well trained and understood just what to do and what I would expect to see at each stage. This is no small feat. It's really (really) hard to visualize the user's system and operate the system by remote verbal control. I know: I've had to do it. He was also smart enough to know that my A21p 3Com laptop LAN card had failed (again) and how to get around that. After about 45 minutes, we were able to resurrect the router and bridge so they could be deployed.
The only beef I have with Buffalo is that it doesn't have a "turn-around" RMA system. That is, if I wanted to send the units back for an exchange, I would have to send them to Buffalo first; it would then (and only then) send me replacement units after a "short" two-day turnaround. That means I would be wireless for about 10 days. Not acceptable! If we hadn't been able to reconfigure the units, they would have gone back to CompUSA.
After mentioning offshoring customer service in an earlier editorial, I have received one anecdote after another from readers, friends, and family who have had similar confrontations with offshore customer support centers. I'm convinced that American companies can't afford to send their customer service departments offshore. The question is, how many American jobs and customers are lost because of this short-sighted attitude toward customer service?
Buffalo Technology goes the extra mile in providing good customer service. I hope they can afford to keep it up. I would hate to have them go the way of the American Bison.
Update: (May 30, 2006) I retired the Buffalo wireless router today. It too was unable to broadcast through the electronic clutter in my house...