Trust, Users and The Developer Division
-- A follow up to what went wrong
-- A follow up to what went wrong
Trust is an important part of any product. If a user can't trust the product and the institution behind it, it is almost inevitable that the product will wither and die. The Apple Newton was a fine product, but it's main point of handwriting recognition wasn't trust worthy and people moved on. They found the Palm Pilot and through its deterministic graffiti system, people found they could trust the recognition and the Palm Pilot became a PDA staple. Even if you look at the Macintosh, it was an excellent product, but, they lost a relationship early on with developers and developers and users moved on to Windows.
The Windows trust and value proposition was always compatibility, low-cost devices, and an open architecture (to name a few). From DOS to Windows, your apps would always just work. If you were a Lotus 1-2-3 for DOS or a WordPerfect for DOS user, everything continued working as you went to Windows 3, 3.1, Win95 (etc). This rang true not with just software you ran on Windows but also with the graphics cards or printers that you connected to your machine; your printers, your modems and other peripherals continued to work. Windows XP did its best with compatibility as a change was made from Windows 9x codebase to the NT codebase. User quickly trusted Windows XP. However, with Windows Vista, a change in the driver model caused a majority of peripherals to simply stop working. Common users lost trust in their operating system for the first time. Windows 7 was better not because of user experience of feature changes, but, two-three years of manufactures fixing their drivers. Windows 7 was simply more compatible and brought back some trust that users lost with Vista. Users became accustomed to that core value proposition of compatibility and low cost.
Guess what, developers are just users too. They may have more patience, but once you continue to show a loss of trust, you risk losing the developers forever.
This takes us to the Microsoft Developer Division or "DevDiv" (approximately 1993 - 2002) and later know as "DevTools" (2002 - 2013). Developer tools at Microsoft started as a series of tools to support the Microsoft DOS and Windows platforms. We had Programmers Workbench which eventually became QuickC then Visual C++and finally Developer Studio. Windows would ship an SDK that included the Windows Resource Compiler, the CHM (help) compiler, Icon Editor and GUI tools (later on) and all the tools you needed to build amazing Windows applications. It had an API strategy that moved forward with each version of Windows. we had Win16 then a transition to 32-bit computing and Win32s and finally Win32. We even had Win64 but you really never needed to think much about it as your 32-bit code simply worked. Over time helper libraries got created. One such was one that Steven Sinofsky helped create called MFC. Borland even created their own competing C++ wrapper called OWL. A developer who used MFC apps would also always work as version by version was created. The last version I used to build applications was MFC 4.2 and it worked well. One amazing benefit of MFC was that it was not trying to be a platform or to abstract away the Win32 API. Instead, you would use Win32 as it was with a Document / View abstraction. If MFC was allowed to mature, it would have been able to blend the latest technologies and APIs into it system.As this was happening, another product Microsoft built, Object Basic and eventually Visual Basic was created by adding support for programming visual forms and connecting to client/server databases]. It added even higher levels of semantics on top of the Win32 API. In fact, it started the complexity and that all of Windows would eventually suffer from. Visual Basic Extensions (VBX) led way to OLE Controls. It introduced arcane notions such as type libraries and OLE Automation. What is interesting to note is that some subsets of what was created with OLE Automation worked well, but, so much technology and subsystems where added, that it became arcane even to the most seasoned developer. All of a sudden, your code would break. If you invested in building VBX to extend VB, magically all that work was for nothing and you had to move to OCX (OLE Controls). The type system you new as TCHAR and UINT was replaced by BSTRs and VARIANTS. In fact, the BSTR was so in compatible because it added a count to the beginning of every string that all of your previous string handling code had to change. Developed for the first time lost trust in Microsoft. The world they new broke. It did not stop, Dynamic Data Exchange (DDE) was soon replaced with a more complicated object linking and embedding protocol. OLE Controls were replaced with ActiveX Controls (even though it was just branding, enough changes were made to infuriate control developers).
I remember sitting in meetings where DevDiv leaders were tired of wrapping the Win32 API. They did not want to be in the wrapper business. This put the developer division on a very dangerous path. All of a sudden they believed they were the platform team.
Something to think about was that it was very much viewed within Microsoft that "wrappers" were not real product development, even with the success of MFC, there was a view that Windows was broken and needed to be fixed. Two things would support such a conclusion: first, the explosion of Windows APIs from about 350 to 1000's; and, second, the Windows folks were not managing API semantics. Using networking was different than using devices than using 3D graphics v 2D graphics and more. Every group came up with their own semantics, callbacks, type systems, event handlers, parameter mechanisms and more. It became impossible to wrap things because some things just couldn't even be wrapped in a language neutral manner. For example, if you would check out the Windows 3 multimedia APIs, http://msdn.microsoft.com/…/…/desktop/dd757331(v=vs.85).aspx or the APIs for using a modem, you would notice the difference in programming models and calling conventions.
This solidified even more as DevDiv went from a mission to being something necessary and money losing to support Windows to a full fledged and highly profitable P&L. Once this happened, DevDiv no longer cared about Windows and moving the platform forward.
The tools took the Office strategy of many SKUs and started bundling everything into Visual Studio. We had to rewrite VB to use the VS shell and this fundamentally changed the VB product and it user base forever. They lost trust in how to even write code and deploy. Their toolset radically changed as Microsoft's focus on revenue optimization outweighed platform considerations and developer trust.
The trust with developers has been a long deteriorating problem. One day we had MFC and the next we would tell developers to use ATL. We would have a constant mess with data telling developers to us RDS (remote data sets) then DAO (data access objects) then ADO, then ADO.net, then LiNQ. If you used data, you were constantly confused by the ever changing API. It was truly awful. Then, everything went to hell when .NET was released. Changes were being made to the C language, to the Visual Basic language. In one fell swoop, Microsoft told all of its developers that everything they were doing and did was wrong. Stop all that crazy C code or the AddRef / Release or that insane VB or Access code and use the new new thing. If you were an ASP developer stop and new become anASP.net developer. While Windows and Office were two largest platforms, DevDiv told the world they were irrelevant and getting tools to support Windows and Office were extremely difficult for 3rd party developers and internally as well. Watching Sinofsky and Silverberg and eventually Allchin argue for support became laughable.
I remember going to COMDEX and giving an Office demo for F1 racing using Excel + Word and real time data acquisition to show how F1 used it in the pits to make adjustments on their cars. The day the CLR released, the message that was received was move or forever be lost. The problem was DevDiv owned the tools. This means the project system, the wizards to start you out, MSDN, everything stopped being about the Windows platform and instead became all about the .NET platform. They even made it hard to find he Win32 Platform SDK to go download.
During the Windows Vista time, there was so much pressure to add the CLR into Windows. The Longhorn team was using it to prototype (or most of Longhorn was a big Flash demo that never really worked). But, part of that was the creation of XAML. Again, we already were in a world of HTML and CSS but the teams were blinded and would use excuses on how they can build a better render tree. XAML was a rewrite of the Window Manager and controls. Even the web browser and the reading experience experience were so heavily influenced by XAML that Microsoft lost time on building a great browser. If the XAML detour did not happen, one could imagine what Microsoft's position could have been with IE and even the popular readers that we see today with Kindle, Nook and iBooks. But XAML was heavy and slow and CLR based. So, internally the Shell team created DUI (DirectUI) which was data driven based like XAML and HTML and the Windows Media Center team created Splash. Office created their own version of DUI that was based on Windows, but then the Windows team abandoned it and Office was left without tools or a platform to gain developer support. All to get away from XAML and the CLR. But what each of these were doing was breaking the years of User32, Shell32, ComDlg32. Instead of enhancing the platform like Microsoft used to do, it was all about rewriting it over and over again.
Even as XAML was being created, an internal group within the XAML team realized it was heavy for "the web" and created a XAML clone and called it Silverlight. This was to compete with Flash. But XAML and Silverlight were not even fully compatible. Developers were livid and frustrated. The Windows Phone team had their own version of a CLR and it wasn't fully compatible with the desktop version. Being a developer for a Microsoft platform was insane. Don't forget Office. One of the largest platforms on the planet. It avoided all this and you still used VBA. Office had to continue to use VBA because there was no guarantee of compatibility between VBA and VB.NET. But now you were an island.
The Windows Phone team did something that would seal its fate forever and lose the trust of developers. Windows Phone 7 was released with a new user experience and was the answer to iOS and Android. It actually got developers excited. But, a year later with Windows Phone 8, Microsoft told all the developers that the investments they made in Windows Phone was a waste of time because none of their apps will work on Windows Phone 8. That was it. It was over. If you aren't Facebook, the. The reason to be on Windows Phone was zero. It had no value. Then you heard Windows management kind of talk about MinWin and a unification of Windows. This meant (to developers) that Microsoft is about to change its mind again and Windows Phone 9 will break everything again. So why bother? While I focus on the client here, this also happened to the cloud and server. I watched Mark Lucovsky stand up at PDC and tell the world about Hailstorm and Nat Brown talk about COM 2.0 and both technologies never see the light of day as a full release or even an open source project. I would watch how OWA API would change and every Exchange App would break.
A side note, there were actually there are two OWA/Exchange APIs and that's why it is so confusing to try to use Exchange on multiple devices, ActiveSync and Exchange Web Access with one used by Windows Phone and the other used by Apple and other 3rd parties.
You only get a few of these breaking moments. The 2000s were all about breaking the platform every years. Developers got fatigue and would give up. It was the decade that changed the trust model for that every developer had with Microsoft. Eventually developers just gave up. You know Hadoop, MongoDB API or Node.js or systems like WordPress or PHP (or whatever open source project) isn't going change and break your code or trust. It was more stable to focus on these platforms as you knew it would run everywhere and not break you.
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.
by:
