Microsoft and developer trust (or lack thereof)

There has been some talk around several internet outlets about the (seemingly) eroding trust developers have in Microsoft and its techniques (see David Sobeski's piece here, Tim Anderson's piece here and e.g. the Reddit Programming thread here). Trust is the keyword here and in my opinion it's essential to understand what that means in the context of a software developer to understand the problem at hand, or even to acknowledge that there is / isn't a problem. I try to explain below what I think trust means in this context.

Every day some individual or team comes up with a new tool, framework, version of an existing tool / framework, new OS or even a new way to bake those nice chocolate cookies. We as humanity tend to call this progress, even though in many occasions the (small) step taken by said individual or team is actually a (small) step sideways or even backwards. To understand why these individuals and teams still come out in the open to demonstrate their results which sometimes result in total lack of real progress, we first have to understand how product development works and why people even do it.

For every successful product (be it a commercial tool/framework/system, open source system/framework/tool or a cookie recipe, you the idea) out there, there are many many more failures, left for dead in repositories on dying harddrives on local servers or cloud storage. The core reason this happens is that there's no recipe for a successful product: to be successful you first have to create something, ship something. No shipping, no success, and as there's no way to know whether success will come after shipping, all we can do is ship as much as possible so the chances are higher that something is picked up and success eventually comes. The rest of the products are ignored, kicked to the curb and eventually moved to /dev/null.

The motivation to keep doing this of course is the vague 'success' term used in the previous paragraph. 'Success' can mean a lot of different things: become famous, earn lots of money, learn a lot, get a respected title, become respected among peers, the list is endless. All these different things motivate people to create new things, to ship their work in the hope it will give them the success they strive for. Microsoft isn't different in that, as a product producer they have to keep on shipping new, relevant products in the hope these products become successful and with that will make the company money so it lives on.

Microsoft has released a tremendous amount of products in the past decades: from frameworks to languages to operating systems to APIs to word processors. Some were successful, others keeled over right after their shiny boxes appeared on store shelves. The successful ones are continued, the less successful ones are abandoned and replaced with a new attempt to gain success. Over time even successful ones were abandoned or replaced because of a different phenomenon: the interest in the product faded, as illustrated in the technology adoption lifecycle.

So in short, Microsoft behaved like any other product producing individual / team: they produced as many products as possible in the hope that as many of them would become successful. That combined with the technology adoption lifecycle in hand, it's clear that to stay successful one has to keep producing products. That is, from the point of view of the product producer. But what about the product consumer, the person who bought into these products, learned how they worked, behaved, what their limits were, in short took a dependency on them? Is the story the same as the one from the product producer?  Sadly, no.

As a software developer we are both product producers (commercial or OSS frameworks/tools/systems or project based custom software) and consumers: we consume frameworks, tools and systems to produce frameworks, tools and systems. To be successful we, like any other product producer, release as many products as we can in the hope that some will gain success. By 'release products' I mean this in the broadest sense: releasing successful custom projects, tools, commercial frameworks or OSS libraries: you shipped software. Shipping custom software written on consultancy basis still contributes to success: the more you ship, the more one will tend to hire you. No-one wants to hire a developer who sticks around for years without shipping anything.

If a product we ship gains success we want to keep that success, so we want to get that bell curve from the technology adoption lifecycle as wide as possible: the wider it is, the longer we can reap the product's success. However there's a problem. To produce this successful product, we took dependencies on the products of others, so our success is tied to the bell curves of those products. If our product can stay successful if the products we took a dependency on stay the same as they are today, the problem is not that big: our clients/customers/users use our product, not the ones we depend on. But what does that mean, 'stay successful'? Is that a given, once the product gets some success?

In most cases, to keep your success you have to keep working on your product: add new features, polish the features already there, remove the ones which don't work anymore, change the looks of the product so it looks new/changed. That way, new users might become interested and take the plunge and will start using your product. As software developers we can only make these changes if the products we depend on let us do so. If the products we depend on are too limiting, it might be the required changes to e.g. make the step from Early Adopters to Early Majority won't be added and the product will never reach the end of the bell curve and will die prematurely.

With writing custom software on consultancy basis this is actually the same thing: there the product you produce is what you can create with the knowledge and skillset you have, those are the dependencies you took. If you are hired to create software which requires knowledge of a product you don't know anything about, you have the same problem as the software producer who creates a software product and who's faced with a framework which is end-of-life: a dependency you took is out of date.

So in the Microsoft world we have on one side the company Microsoft who cranks out products like there's no tomorrow, and on the other side we have developers using these products to create new products, depending on the products Microsoft produces. As soon as Microsoft abandons a product, all developers who took a dependency on that product, either through knowledge for their consultancy work or for producing software with it, inherit a problem through that abandonment: their own products now run the risk of following the same road as the abandoned Microsoft product.

There are several solutions for this: take a dependency on an alternative product, e.g. from a 3rd party vendor/team/individual, rewrite the functionality the dependency was all about yourself, keep on using the (soon to be) outdated product or abandon your own product as well and create a new one. All have their side effects and all have some things in common: they all come with pain, loss of time, risk of losing the success and therefore loss of money. And all that for no gain at all: if the product wasn't abandoned, the software producer could invest the time in the successful product instead, which would benefit the user.

Taking a dependency is therefore a risk: if the product we depend on has a bell curve which doesn't match our own product, i.e. our product's bell curve is wider / ends later, we run the risk that our product will suffer from the fact the product we depend on reaches end-of-life and will be replaced and abandoned. To mitigate that risk, software developers therefore want to align the bell curves of their products with the ones they take a dependency on: if the products they depend on outlive their own products, they have nothing to worry about, give or take some breaking changes along the way.

But how do you know this bell curve of a product you take a dependency on? Well... you don't. Chances are the product producer doesn't even know for sure how the bell curve of the product is or will run: no-one can predict the future and especially not about products. All that is left is trust and hope: trust that the producer of the product you took a dependency on will keep producing the product in a form you can use and hope that the producer stays trustworthy. There's no certainty, only those two: trust and hope.

If the producer of products you depend on becomes untrustworthy, things fall apart: you can't trust them anymore to keep producing the product in a form you can use and therefore you have to acknowledge there's a problem: your own product has a higher risk of ending prematurely unless extra work is done to mitigate the risk. The core issue at play here is: who is doing that extra work. 

As mentioned earlier, Microsoft produced and produces a lot of different products on a high speed. This isn't new and the problems for developers with prematurely ending lifecycles isn't either. In that light, one can't say Microsoft has become less trustworthy: if one trusted Microsoft in the past, what's there against not to do that today? However there is something which is new and which wasn't that much of a problem in the past due to monopoly positions: who's going to pick up the inevitable tab when a product is abandoned? Is it Microsoft so it will invest in ease of transition from the abandoned product to the replacement product, or is it the developer who took the dependency on the abandoned product and now has to invest in migrating her/his own product to a replacement product?

In the past, Microsoft did invest sometimes in transition technology but most of the time it didn't and the software developer who took the dependency was forced to invest the time to move to an alternative/replacement product. The developer did this as there was not really a real alternative. However today there are. Plenty. However Microsoft plays the same game as they have in the past: make the transition from abandoned product to a replacement the problem of the developer who took a dependency on the abandoned product, but with the alternatives growing wider in scope and more mature every day, it's not a given anymore that a developer will pick up the tab: if time has to be invested in migrating the product to an alternative, it might as well be wise to migrate the product away from all dependencies on Microsoft products.

The core motivation for doing that is, in my opinion, that there's severe lack of trust and hope that Microsoft takes the responsibility for the effects a premature end-of-life of a product will have, at least for a group of products. Code written against win32 15 years ago will likely still run today and will also do so tomorrow. It's a different story with .NET based applications even when .NET is a virtual machine based system and therefore could abstract away migrations to the products it depends on (underlying system/OS). At the same time the visibility and availability of mature, trustworthy alternatives elsewhere lowers the chance for Microsoft to get away with a lack of responsibility.

In my opinion, trustworthiness is closely tied to how much responsibility you want to take for the lifecycle of your product and thus for the effects the end of the bell curve will have on the people who take a dependency on your product: the more responsibility you're willing to take, the more people will trust you with their dependency as they know the risk for their own products is lower. Microsoft blew this on several fronts and on several occasions in the .NET world.

But is that really anything new? No, it has happened countless times before. In fact, the trust implied by the willingness of developers to pick up the tab in the past is in my opinion an illusion: there was never really any trust, there was just a large 'it is part of the game' acceptance among developers, largely due to lack of knowledge how things were done elsewhere. Compared to those other times, todays world is a different one than the one 10-20 years ago: Microsoft can't get away with it easily anymore: developers know there are other realms, other worlds out there who suffer less from a single company who calls the shots and more importantly: is not willing to face the consequences for developers when products are abandoned.

That's the real problem Microsoft is facing today with respect to developers: will they trust Microsoft enough that they are willing to take a new dependency on the new stuff Microsoft is producing, even though they know the pain will likely be as severe as it is today? Frankly, I doubt it, or at least, the group blindly doing so will be smaller and will do it with less enthusiasm. Simply because there's less reason to.

For the developers who need to take dependencies on Microsoft products, let's hope they realize they need to step up and take responsibility for the effects abandoning products will have on developers. Only then Microsoft will regain the trust it had.

PS: I am fully aware I produce a product which has many customers who take a dependency on it and at the same time has a few dependencies on Microsoft products like .NET, C# and ADO.NET and thus that this essay also applies to my work. The key take away is responsibility: the actions one takes, which effects will these have on the people who took a dependency on your product? I've spent many many months during the past 10-12 years to mitigate those effects as much as possible for my users and will continue to do so, additionally to the offerings like full sourcecode and rich extensibility points for most elements of my system to lower risks for users. This to answer questions people might get when reading the above text.

Published Thursday, January 23, 2014 1:55 PM by FransBouma

Comments

# re: Microsoft and developer trust (or lack thereof)

Thursday, January 23, 2014 8:26 AM by Garry@TriSys

Good points which are all mainly correct.

Microsoft ought to have simply looked at the history of their successful products. Visual Basic was a success because it greatly simplified writing windows applications by comparison to the 100+ lines of "Hello World" C/C++ code required in the early 1990's. Todays Visual Studio C# borrows so much from the work of Alan Cooper and the VB team. .Net was a success because it abstracted the complexity of Win32 and provided a better way of building windows apps.

Why, oh why did Microsoft not do the same by producing developer tools which abstracted the complexity of building modern web and mobile apps? Did they lose their way and forget history?

# re: Microsoft and developer trust (or lack thereof)

Thursday, January 23, 2014 8:31 AM by Khalid Abuhakmeh

This might sound counter-intuitive, but for Microsoft to be more responsible (or any product for that matter), it needs to delegate responsibility to as many people as it can. The more people who feel a sense of ownership, the more likely the product will take a life of it's own. The original owner just has to be willing to pass the torch on. When it comes to Microsoft there are conflicting business interests that want to see products die so they can sell the next new and shiny thing, and they don't want the ghosts of the past to haunt them.

I agree with you taking a dependency is always a risk, and some risks pay off and some don't. That said, most of the dependencies I take today are OSS. If worst comes to worst I can always lean on the community that took the same risks that I took, and we all know we are in the same boat, even if that boat is the Titanic :)

# re: Microsoft and developer trust (or lack thereof)

Thursday, January 23, 2014 3:45 PM by A

One element of trust for me personally.

I no longer trust Microsoft to make the next version better than the current version.

For example: I used to be one of the people who would push for upgrades to VS but now I only upgrade VS when required.

I've been using VS since 6.0 but if I were to start a personal project, I would spend the time to look at other tools before spending my own money on VS.

# re: Microsoft and developer trust (or lack thereof)

Thursday, January 23, 2014 6:09 PM by David Taylor

Thanks - well written and interesting take.

Of course there is only so much Microsoft can do to assist transitions, but yes they can do more than they are currently doing.

# re: Microsoft and developer trust (or lack thereof)

Friday, January 24, 2014 10:29 AM by Khalid Abuhakmeh

@Garry Abstractions are not always good. Take the abandonment of ASP.NET WebForms by the larger web development community. Sure it abstracted the web away, and put a stateful event driven architecture on top of a stateless request response driven protocol. It is beautiful in its madness, but I wouldn't want to go back there anytime soon (although SPA might be dragging us back there kicking and screaming).

# re: Microsoft and developer trust (or lack thereof)

Friday, January 24, 2014 3:22 PM by Jeff

I find this entirely line of discussion borderline ridiculous. There are .NET apps running in production all over the place that are a decade old. Nothing Microsoft has done broke those. Now we're even entering a world where the source for much of the stack, especially at the web end, is open source. You can actually have the source, and keep it forever, if you so choose. Nothing Microsoft will do will break that.

# re: Microsoft and developer trust (or lack thereof)

Saturday, January 25, 2014 12:29 PM by James Hancock

The issue is that Microsoft keeps creating new frameworks that are half-baked and making coders re-write and are trying to use these frameworks to push Windows upgrades.

If Microsoft wants to regain developer trust:

1. They must commit to 1 and ONLY 1 framework. That is, .NET in general for server side and ONLY Windows Store apps going forward. (See #2)

2. They must back port Windows Store Apps to Windows 7 and support it in a window and provide access to the Windows Store of course. (like Windows 9 will support)

3. They must support Windows Store Apps on Xbox and allow developers to target it at the same terms as Windows itself.

4. Windows Phone must have parity with Windows Store Apps against the API.

5. MVC.net stack needs to have it finished being cleaned up. That is, get us a complete story for building MVC.net + HTML 5 + Typescript + Knockout + Web API + Entity Framework that is both clear, and auto generates most of the code. I.e. I should be able to write a DTO and a Web API endpoint on the server, and have it automatically exposed in Typescript with a generated library of both strongly typed Web API calls, and DTOs to work against. Further it should be auto-generating the Knockout view-models for me. And no, I don't want to expose my entities directly, so don't force that on me.   Also make it auto-generate a portable .NET library that works on Windows Phone, Xbox, .NET apps, windows store apps, and Xamerian Android and iOS so I can target all of them. (Better yet, buy Xamerian, and create a 100% native compile environment for Android and iOS that allows development in Visual Studio in one solution handling all 3.)

Right now we have all of the bits and pieces but the work involved in doing it is ridiculous repetition or you have to write T4 scripts which Microsoft barely supports.

6. Windows Store apps can't be crippled. If you want to charge for MPEG2, MKV, DD TrueHD, DTS-HD, fine, do so as a one click add-on pack that will prompt if you try and play any of these formats that stays with the CD Key used to install Windows and is transparently re-installed if the OS is. I understand the licencing costs, but your platforms need to be able to support them, and the current state where desktop apps can support these easily and there is virtually no support for Windows Store apps makes this untenable and is alienating the tech crowd that you need to win over.

7. Don't keep killing things like Windows Media Center unless you have a replacement (and no, Xbox with a gold account is not a replacement).  Put the scheduler, guide and turner functionality back in as a service under windows that is included in the Essentials version of Server (and can be installed on any version of server) and the desktop. Once installed that will work as the server. It should be able to be installed automatically if an app requests it and the user says yes. Give all Windows/Xbox/Phone devices that are registered with it access to stream from it anywhere. Give us cable card and cablecard 2 support and push DirecTV and Dish to support it as well and the new DLNA support too so that the server can do everything.

And finally, create a front end in a Windows store app for this service and allow it to just work on any device. And even more to the point: Give 3rd party apps the ability to access this stuff too.

8. Build a Microsoft Cube Server with snap on additional hard drives and tuners (i.e. 1 or more cable cards snapped on the top, or directv/dish tuners or OTA etc. and 1 or more hard drive units snapped on the bottom that automatically get provisioned and the space automatically available.) Make it headless and make it plug and play and automatically show up on every device in the home.

Then make an xbox lite that does nothing other than be a media client. HBO, Netflix etc. of course for streaming, but also for TV, media, videos, photos, everything, all automatically stored on the central drive with a one click setup on all of your devices, and optional backup of photos and videos to skydrive for safety. If you did this so that it was no more difficult then plugging in a bunch of wires and everything else just happened automatically, (which is 100% possible) you'd own the living room.

If you do these things you will:

1. Regain confidence from developers

2. Provide clear stories for developers to quickly and easily create enterprise grade applications.

3. Be able to target all of the markets that you want to target, and provide a platform that end users and developers want to use.

4. Be able to take back the phone and tablet market, because if you provide a single IDE for developing for Windows, Android and iOS that builds native, best of breed apps with a huge amount of code share natively, developers will use it to save time, and if you do that, you win, because you have the developers using your tools by default.

5. Win back the hackers and hobiests.

6. Be in control of your own destiny by having your own hardware instead of what happened to Media Center, which was bad hardware on a system that was too hard to setup. You can make it brain dead simple and by owning the hardware you know the quality is there so the platform won't get killed with bad reviews.

This is where the next MS CEO needs to get to. He/she doesn't need to be selling off divisions, they need to be more tightly integrating them, and making things JUST WORK. No more Lync Server installation PITAs. No more Media Center "it works great if you can set it up", no more Xbox pay-wall to use the basics like Netflix etc. No more hamstringing and half-baked API layers. No more half-baked messages that are half measures and half done.

(and yes I'm a huge MS fan, and I know exactly how you can accomplish these things quickly over the next 18 months if you have a clear, singular vision to get there.)

# re: Microsoft and developer trust (or lack thereof)

Saturday, January 25, 2014 2:27 PM by Miha Markic

James, supporting only Windows Store is bad. There are a ton of application even for XP out there. And what about many WPF applications? WinForms? Should we rewrite all that?

# re: Microsoft and developer trust (or lack thereof)

Sunday, January 26, 2014 7:19 AM by Fadi El-Eter

Hi Frans,

I read your whole post, and I noticed that you keep on mentioning, subtly, that other companies are better than Microsoft in that regard. Can you please tell me which? I can't think of a single mega IT company that cares about the ecosystem around its products as much as it cares about its numbers. Yes - this is part of the game - and we've all accepted it.

At my business, we support PHP, Joomla, and WordPress - now. All are products and all, like any other product, have a lifetime. They're all healthy at the moment, but we don't know what's going to happen in 10 years from now. What if they are discontinued and we are still supporting them? Who's to blame? In my opinion, the real ones to blame are us, because it's nearly always obvious when a product is dying, and, when this happens, one should jump ship to another one.

# re: Microsoft and developer trust (or lack thereof)

Sunday, January 26, 2014 8:14 AM by FransBouma

@Fadi:

IBM for example: in DB2 they deliberately keep statements /syntax around so code written 2 decades ago still runs and works properly.

# re: Microsoft and developer trust (or lack thereof)

Sunday, January 26, 2014 8:55 AM by Yves Reynhout

This is exactly the reason why I've stayed away from anything mainstream (apart from the BCL) for the last 10 years or so ... They can change their mind as many times as they want about the stack on top of the BCL, I don't give a flying ... I'd rather bet my money on OSS, TBH.

Yes, there have been many times when I needed to make a trade-off between build it yourself and taking a dependency. If it was strategic, the dependency route - more often than not - lost. True, communication, database, security infrastructure (to name a few) shouldn't be done by oneself (or a team of likeminded individuals) unless you have a tremendous amount of pre-cog on the subject matter. Most often that is not the case.

Something you didn't mention (which may be attributed to the fact that you are a "product" developer yourself), is the difference between projects and products. "Consultancy" mainly does "projects", shorter term gigs. The cause and effect of taking a dependency is not noticed nor felt by the ones making the choice. It's the ones that come after that have to deal with the "pain".

I think you hit the nail on the head, sentiment wise, with this post. Well done.

# re: Microsoft and developer trust (or lack thereof)

Sunday, January 26, 2014 2:31 PM by Stacy

What people forget is that this is Microsoft's business model. They make their money by disrupting our tools so we buy/upgrade more. Period. Maybe in the future via Azure, we'll pay continuously(subscriptions) for tools, and therefore little need for disruption as a biz model.

# re: Microsoft and developer trust (or lack thereof)

Monday, January 27, 2014 9:23 AM by James Hancock

Miha Markic: Winforms is legacy. Leave it in the .net framework. So is WPF, legacy it, support bug fixes and leave it in the .net framework.

But commit to Windows Store's API and only that API.

And just as important, allow people to install these apps out of the store too.

# re: Microsoft and developer trust (or lack thereof)

Monday, January 27, 2014 9:32 AM by James Hancock

Stacy: The point is that Microsoft needs to change it's business model. The world doesn't work that way anymore.

It's time for an integrated, consistent architecture that is portable across all platforms, and a development tool that works best for Windows, but can build backwards to iOS and Android. MS has done this in the past and they need to do it again, but they also need to get one central vision from a technology perspective.

In short they need a highly technical leader that can reign in the politics at Microsoft and drive everyone to a single goal: Seamless integration on all fronts, with fall back to competing platforms.

# re: Microsoft and developer trust (or lack thereof)

Monday, January 27, 2014 1:46 PM by wekempf

There will always be devs who lose trust when new frameworks "replace" old ones, but frankly, that's not what the real issue here is. ADO being replaced by ADO.NET caused some feathers to be ruffled, but most developers kept trust. Why? Because the bell curve didn't end for ADO when ADO.NET came out. Our solutions based on ADO still work today.

The problem is, that level of trust is now violated. Silverlight is dead. It's not just a matter of focus going somewhere else, Silverlight died. If you have existing products using Silverlight your product is probably already at EOL, and at most you'll get another year or two out of it if you're lucky enough that it's still being used.

WP7 is dead. Yeah, most of your code ported to WP8 with little or no changes, but that's still a place that Microsoft killed the tech you depended on. Long term support simply doesn't exist. Your WP7 products are at EOL now.

Both of those had unbelievably short life times, and truly came to an end, rather than being relegated to legacy support. That hurt. Bad. That's why we see devs losing trust and abandoning Microsoft now, but we didn't the hundreds of other times new frameworks were released.

In any event, the question on the table isn't so much about how the lost trust (much less whether they lost it) but rather how can they gain it back? Because if they don't gain it back, it may well be game over for them.

# re: Microsoft and developer trust (or lack thereof)

Monday, February 10, 2014 8:18 AM by Courtney

Microsoft shouldn't waste their time on Win8 apps.  They should really have extended/completed WPF properly.

Microsoft seem to have forgotten many businesses depend upon LOB systems - and these systems need to have a decent life expectancy for our clients to receive value.

They dropped the ball completely with killing Silverlight.  The issue was they actually held roadshows months before promoting it as a platform (and really ignoring desktop systems).

In the mobile space you would have to be crazy not to use iOS or Android.  Even for our Windows LOB systems, mobility extensions are on Android.  Why would clients pay more for a tablet and also pay for sideloading (even big companies do not necessarily have an infrastructure for win 8 app deployment).

As a business we made an investment in up-skilling for WP7 which in reality was a complete waste.  We didn't bother extending our MSDN Mag subscription - in reality it wasn't relevant to us any more.  We don't do Win 8 apps and don't have plans to.

At the end of the day I produce solutions for my business clients.  They care it meets their requirements, not the exact technology.  Microsoft have spent a lot of effort targeting the production of apps and an app store.  

Despite promises otherwise they really have neglected LOB developers.