David Sobeski, former Microsoft General Manager, has written about Trust, Users and The Developer Division. It is interesting to me since I recall all these changes: the evolution of the Microsoft C++ from Programmer’s Workbench (which few used) to Visual C++ and then Visual Studio; the original Visual Basic, the transition from VBX to OCX; DDE, OLE and OLE Automation and COM automation, the arrival of C# and .NET and the misery of Visual Basic developers who had to learn .NET; how DCOM (Distributed COM) was the future, especially in conjunction with Transaction Server, and then how it wasn’t, and XML web services were the future, with SOAP and WSDL, and then it wasn’t because REST is better; the transition from ASP to ASP.NET (totally different) to ASP.NET MVC (largely different); and of course the database APIs, the canonical case for Microsoft’s API mind-changing, as DAO gave way to ADO gave way to ADO.NET, not to mention various other SQL Server client libraries, and then there was LINQ and LINQ to SQL and Entity Framework and it is hard to keep up (speaking personally I have not yet really got to grips with Entity Framework).
There is much truth in what Sobeski says; yet his perspective is, I feel, overly negative. At least some of Microsoft’s changes were worthwhile. In particular, the transition to .NET and the introduction of C# was successful and it proved an strong and popular platform for business applications – more so than would have been the case if Microsoft had stuck with C++ and COM-based Visual Basic forever; and yes, the flight to Java would have been more pronounced if C# had not appeared.
Should Silverlight XAML have been “fully compatible” with WPF XAML as Sobeski suggests? I liked Silverlight; to me it was what client-side .NET should have been from the beginning, lightweight and web-friendly, and given its different aims it could never be fully compatible with WPF.
The ever-expanding Windows API is overly bloated and inconsistent for sure; but the code in Petzold’s Programming Windows mostly still works today, at least if you use the 32-bit edition (1998). In fact, Sobeski writes of the virtues of Win16 transitioning to Win32s and Win32 and Win64 in a mostly smooth fashion, without making it clear that this happened alongside the introduction of .NET and other changes.
Even Windows Forms, introduced with .NET in 2002, still works today. ADO.NET too has been resilient, and if you prefer not to use LINQ or Entity Framework then concepts you learned in 2002 will still work now, in Visual Studio 2013.
Why does this talk of developer trust then resonate so strongly? It is all to do with the Windows 8 story, not so much the move to Metro itself, but the way Microsoft communicated (or did not communicate) with developers and the abandonment of frameworks that were well liked. It was 2010 that was the darkest year for Microsoft platform developers. Up until Build in October, rumours swirled. Microsoft was abandoning .NET. Everything was going to be HTML or C++. Nobody would confirm or deny anything. Then at Build 2010 it became obvious that Silverlight was all-but dead, in terms of future development; the same Silverlight that a year earlier had been touted as the future both of the .NET client and the rich web platform, in Microsoft’s vision.
Developers had to wait a further year to discover what Microsoft meant by promoting HTML so strongly. It was all part of the strategy for the tablet-friendly Windows Runtime (WinRT), in which HTML, .NET and C++ are intended to be on an equal footing. Having said which, not all parts of the .NET Framework are supported, mainly because of the sandboxed WinRT environment.
If you are a skilled Windows Forms developer, or a skilled Win32 developer, developing for WinRT is a hard transition, even though you can use a familiar language. If you are a skilled Silverlight or WPF developer, you have knowledge of XAML which is a substantial advantage, but there is still a great deal to learn and a great deal which no longer applies. Microsoft did this to shake off its legacy and avoid compromising the new platform; but the end result is not sufficiently wonderful to justify this rationale. In particular, there could have been more effort to incorporate Silverlight and the work done for Windows Phone (also a sandboxed and touch-based platform).
That said, I disagree with Sobeski’s conclusion:
At the end of the day, developers walked away from Microsoft not because they missed a platform paradigm shift. They left because they lost all trust. You wanted to go somewhere to have your code investments work and continue to work.
Developers go where the users are. The main reason developers have not rushed to support WinRT with new applications is that they can make more money elsewhere, coding for iOS and Android and desktop Windows. All Windows 8 machines other than those running Windows RT (a tiny minority) still run desktop applications, whereas no version of Windows below 8 runs WinRT apps, making it an easy decision.
Changing this state of affairs, if there is any hope of change, requires Microsoft to raise the profile of WinRT among users more than among developers, by selling more Windows tablets and by making the WinRT platform more compelling for users of those tablets. Winning developer support is a factor of course, but I do not take the view that lack of developer support is the chief reason for lacklustre Windows 8 adoption. There are many more obvious reasons, to do with the high demands a dual-personality operating system makes on users.
That said, the events of 2010 and 2011 hurt the Microsoft developer community deeply. The puzzle now is how the company can heal those wounds but without yet another strategy shift that will further undermine confidence in its platform.
I believe he is right, but from a business/enterprise perspective. For consumer devices deveopers surely go where the users are, but the enterprise business is likely a larger business for Microsoft, and there, they have lost all the trust they once had. In the Enterprise World code bases live 10+ years easily, there has to be trust to make the investments in a fairly slow, but definitaly expensive, environment worth it. Before you would chose MS Stack because you knew it was stable, it was a bonus, but often it was also more productive. Their stack is often still more productive, but now you are scared you will be faced with a rewrite that is just sometimes really difficult to get a budget for.
They sacrificed way too much by not making WPF/SL stick in that world, this is why LOB/Enterprise are ware of commiting to the stack, in the end, this is how MS software got popular, not through consumer success, but from Enterprise familiarity, what you used at work you kept using at home.
If they can make WinRT into what Silverlight promised, make it work on Android/Linux/Mac fairly seemless and at least be a stable platform on Windows, they will regain some trust. Microsoft have so much potential and so many opportunities that other companies dream of, wish they could execute on those opportunites.
If they had just kept SL side by side with WinRT for awhile trust would not have been lost.
Tim, you say you disagree with this conclusion:
“At the end of the day, developers walked away from Microsoft not because they missed a platform paradigm shift. They left because they lost all trust. You wanted to go somewhere to have your code investments work and continue to work.”
But for me (and my team) this was a major reason to go from Silverlight to html5. This was no light decision, but we do not regret it.
Your argument that developers go where the users are is true, but often there is more than one way to the user :-).
So, what could Microsoft do to restore trust? The first step is to stop the Sinofsky-an secretiveness. I already see the first signs of this.
One thing which has also really bothered me, was the silly “it’s all XAML” silliness, which implied that all our investments are save, because the new platform is also XAML-based. PLEASE, stop this bullshit. Developers are sometimes silly, but not that silly.
I think Sobeski’s conclusion is mostly correct.
If Microsoft had allowed us to build WinRT apps using .Net, we would still be a Microsoft-Only ISV.
We built 1 WinRT app which provided zero code re-use from our .Net code-base.
As a result of Microsoft abandoning us however, we are now developing cross-platform web and mobile applications targeting non-windows devices. We also use AWS instead of Azure because we fear that they could do the same abandonment in future and do not want to put all our eggs in the Microsoft basket ever again.
Sorry, I find it hard to take seriously the opinions of a guy who still, in the year 2014, writes stuff like: “It will become a Linux problem. It’s open source nature allows hackers to easily find its vulnerabilities.” — https://www.facebook.com/dsobeski/posts/10153719512980008
(Complete with followers spouting the likes of “I believe that Windows is the most secure operating system out there”, asserting it’s “still not perceived as secure” just because “Windows get attacked more than anything else”…)
Sigh. How often must this stuff be debunked, to frigging STAY debunked?!?
Hi Tim,
Personally, I think that support of Windows tablets will increase with time, since Microsoft is investing a lot in that area…
I do think that Microsoft wasn’t consistent enough lately, but this is the case with all the other major IT companies – the problem is, Microsoft was ignoring some very important products. Personally, I stopped developing anything around a Microsoft product back in the early 2000s, when Microsoft moved away from ASP to .net (I was an ASP developer back then). What I really didn’t like about Microsoft product is that you had 2 business layers – one in your code, and one on the server (COM objects – if anyone remember what they were), and then Microsoft came with its own version of Java (.net), and confused many developers (including myself), as if things weren’t confusing before.
Going back to the original point – I think it’s the job of the developer to protect himself against upcoming changes with the products he’s servicing. Companies are allowed to do whatever they want, and developers should always be proactive; they should walk away on the slightest hint of an upcoming product termination.
Thanks for sharing…