I missed the TechEd keynote this year. I usually attend so I can gauge how the latest Microsoft message is getting across to the developers, managers and (especially) to the Microsoft people whose products are being touted. Last year was, well, a disaster for many that attended. Actually, I'm sorry I missed it-but then again, I needed to get some rest after another grueling day of flying. I got to the hotel about 3:30 AM. "Weather" was the excuse this time but I expect overbooking, maintenance issues and running the fleet at 110% capacity were contributing factors. No one can be expected to run any organization or machine at that RPM for long. I've worked for companies big and small (including Microsoft) that tried it. It's funny how the result was always the same. We seemed to get a lot done, but once we had shipped, the cycle began again the next morning to fix the stuff we missed in the rush to RTM. Thankfully, I read Mr. Jones' editorial in Developer.Com (6/12/07) to review what I had missed. I think it's kinda ironic that Microsoft would use the "Back to the Future" theme for the keynote. Yes, I agree, they have lots of new and (apparently) much anticipated products and upgrades in the wings.
For me, TechEd is a time to give a couple of presentations, sell a few books and (most of all) get a finger or two on the pulse of the developer community. I spent considerable time (when I was not cowering from the lightning) interviewing anyone who would talk. These conversations took place before and after my sessions, in the speaker's lounge (which was more like a closet this year), at lunch, at the Technical Learning Center booths and (to a lesser extent) at the parties. Because I was not wearing a Microsoft shirt, I think folks had a tendency to open up a bit more. The consensus was that not everyone is all that excited about the future versions of the products Microsoft is touting this year. The vast majority of the people I spoke with really wanted to get a better idea how to get the stuff they bought two and three years ago to work. No, they weren't really trying to figure out how to get SQL Server 2000 to work-those folks have a lot of resources and experience on which to draw. What they need help on is Visual Studio 2005, SQL Server 2005 and the "ancient" stuff created, promoted and sold a short three years ago. They want help on getting these tools, server and the applications they generate to work together and to work on Vista. I heard from many companies that were dealing with the JET virus-as a result were trying to figure out how to migrate to SQL Server Express or Compact editions. Some had just learned about Reporting Services and wanted to know how to display rich text or schedule a report. Few were excited to hear that if they install SQL Server 2005 SP2 that if they activated the SharePoint feature many of their Report Manager settings would slip into the bit bucket.
Out in the trenches, developers working in companies large and small have a wide range of skills, motivation, resources and training. In addition, most of the companies I work with are pretty conservative. No, not conservative like the people who would ban nasty dancing at the prom, but conservative in that they don't charge off into the unchartered swamps of the latest technology. These folks are just now starting to convert to SQL Server 2005-years after the launch. Could they use the features in Katmai (now dubbed SQL Server 2008)? Sure, they might. And one approach SQL Server 2000 customers consider is to wait until 2010 and skip the 2005 tools altogether-and some are just now converting from SQL Server 7.0.
I've interviewed developers, managers and architects that have felt left behind by Microsoft's rush to innovation. Sure, there are really good reasons to build safe, stable and high-performance platforms and make them sexy enough to sell to the general public. But the speed at which these products are pushed out the doors in Redmond is unprecedented. Last year Steve Ballmer and Ray Ozzie told the TechEd 2006 developers to expect more "disruption" and more frequent software updates. Ah, guys, many companies don't really mind if the software to which they're migrating has been designed a bit better, refined a bit longer and does not need to be patched weeks after it ships to correct a major bug (or two). The last time I met with Microsoft at a software design review, the folks in attendance (a who's who of development gurus) made it abundantly clear that Microsoft needed to do more about this constant thrash of technology. They wanted to see more bug's logged into Connect as "fixed" and fewer tossed aside as "postponed", "by design" or simply "won't fix". They wanted to see documentation that's complete and accurate and matches the shipping products.
Sure, all of this takes time and resources. Given Microsoft's wealth and market share, it should be within its grasp. It also takes a firm grip by management to make sure that the marketing people (who seem to have nothing else better to do than rename existing products) don't over-hype or make promises that can't be kept. Management needs to control the young lions whose innovative ideas are cool but require the developer community to retool, rethink, redesign, recode, retest, redeploy and reinvest in training and support teams every 24 to 36 months.
Of course, I think it's Microsoft's job to innovate. As a stockholder I want them to succeed. They are in a unique position to do just about whatever they want. However, since they have created the development platform virtually all developers must use (Windows), they also have a responsibility to respect the billions of dollars and man-years invested in designing, training, building, supporting and selling applications that depend on this platform. Microsoft's software development tools, platforms, services and engines are the foundations upon which developers all over the world depend. If they are constantly changing, they can't be expected to stay in business or stay competitive-that includes the developers' companies and Microsoft itself. To this end I think Microsoft needs to decide on a development platform, get it working and stick with it.
About the Author
|William (Bill) Vaughn is an industry-recognized author, mentor and subject-matter expert on Visual Studio, SQL Server, Reporting Services and data access interfaces. Hes worked in the computer industry for over thirty-five yearsworking with mainframe, minicomputer and personal computer systems as a developer, manager, architect, trainer, marketer, support specialist, writer and publisher. In 2000, after 14 years at Microsoft, Bill stepped away to work on his books, mentoring and independent training seminars. Hes written seven editions of the Hitchhikers Guide to Visual Basic and SQL Server and three editions of ADO.NET and ADO Examples and Best Practices for Visual Basic (and C#) Programmers. He and Peter Blackburn also wrote the critically acclaimed Hitchhikers Guide to SQL Server 2000 Reporting Services. Bill is a top-rated speaker and frequents conferences all over the world including TechEd, Visual Studio/SQL Connections, DevTeach and many others. Hes also written a wealth of articles for magazines such as MSDN, SQL Server Magazine, Visual Basic Programmers Journal, .NET Magazine and many others as well as a regular editorial for Processor magazine. Bill spends considerable time answering questions on the public newsgroups and speaking at INETA user group meetings all over the country and at other speaking venues all over the world. Hes available for consulting, mentoring or custom training. See www.betav.com or www.betav.com\blog\billva for his current schedule and course catalog.|