Redmond Review

Windows 8: Times Are Changing for Developers

Microsoft's BUILD announcements about Windows 8 and other technologies are a break from the past.

On Sept. 7, I took my son to his first day back at school, which was good preparation for Sept. 13 when, in a sense, I went back to school myself, by attending the Microsoft BUILD conference. Along with my classmates (about 5,000 Microsoft-focused developers), I lined up outside of school (the Anaheim Convention Center Arena) to attend my first day of classes (the day-one keynote and "Big Picture" sessions) and get an overview of what I'd be learning this year.

At BUILD, we learned about "Windows 8" and the Windows Runtime (WinRT). We learned about "Metro style" applications and the various ways of writing them, ranging from HTML5, CSS 3 and JavaScript to C#, Visual Basic and .NET. We learned about the Windows Store, about applications that should look and work in a "fast and fluid" manner, and we learned how those applications would coexist with their opposite numbers on the Windows desktop.

BUILD is now well behind us, and the development of Windows 8 lies before us. With that in mind, let's take inventory of what Microsoft shared with us that week in September, form some conclusions about what it all means and think about what lies ahead.

Fears Overblown; Changes Not Imagined
First and foremost, let's acknowledge that Microsoft is offering a comfortable path for .NET developers and a shallow-sloped onramp for them to Windows 8. Many people fretted away their summers worrying that C# and Visual Basic -- and the developers who use them -- would have no entrĂ©e into the new Windows 8 world. In my March column this year ("Microsoft, Windows Azure and Assisted Transitions"), I remarked how Microsoft's track record of helping developers through platform shifts was excellent; the BUILD message leaves this record untarnished. In my June 23 Redmond Diary post, I conjectured that HTML and JavaScript were vehicles for bringing in new developers, not forcing out developers already in the Microsoft camp. BUILD validated this conjecture. That makes me happy -- not just for my record of accuracy, but also for Microsoft's record of holding developers in very high esteem.

But make no mistake: Windows 8 marks a change for Microsoft. Yes, Metro apps can be developed in .NET. But HTML, CSS and JavaScript seem at least a little closer to the Metro "metal" and, surprisingly, with their more-welcoming home in Visual Studio, using them doesn't seem so crazy. Microsoft's message in the fall proved the summer's panic in certain circles unfounded. But Microsoft's uncharacteristic secrecy this summer was nonetheless real, and it was at least a little uncomfortable for most of us. This message discipline probably wasn't an anomaly, either; it's likely going to be a standard approach for Microsoft going forward.

Momentum and Loss
So where does this leave us? What should we think? No, Microsoft's not irrational, and it hasn't lost respect for its developer elders. But yes, things are changing. The platform is changing. Microsoft's approach to dissemination of information is changing. And while Microsoft does nearly always assist developers in transition, it doesn't eliminate those transitions -- nor can it prevent all their discomfort. Computing careers are a bit paradoxical: As developers, we reach equilibrium when platforms stabilize, but those platforms (and we) lose competitive value if stasis sets in. Our achievements must be disrupted in order for us to prosper.

Microsoft is no different. Whether it's Apple and Google/Android at the consumer end, or Oracle, IBM, SAP and others on the enterprise side, Microsoft is facing unprecedented, unrelenting competition. It has to change. It has to upset its own equilibrium. Not just in its technology stack but in its market approach, too, and even in its corporate culture.

The company can't disregard, nor disrespect, its heritage. But it must view that heritage in industrial and competitive context, and recognize that as this context changes, the company must change as well. That's what I learned at BUILD. As I had hoped and expected, things aren't all doom and gloom. But they are different, and this difference, in a real way, involves loss.

The back-to-school analogy applies. The transition from senior to freshman is perhaps the hardest. Stature and security slip away. But sometimes, incurring loss puts wider horizons within reach.

About the Author

Andrew Brust is Research Director for Big Data and Analytics at Gigaom Research. Andrew is co-author of "Programming Microsoft SQL Server 2012" (Microsoft Press); an advisor to NYTECH, the New York Technology Council; co-moderator of Big On Data - New York's Data Intelligence Meetup; serves as Microsoft Regional Director and MVP; and is conference co-chair of Visual Studio Live!

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube