The Microsoft Tax

I recently read a piece from Scott Hanselman about the irrational hatred some have for Microsoft. His argument boils down to this: “Microsoft is not the open-source hating, embrace-extend-and-extinguish evil empire it once was. We love open source, we make great tools, and developers should give us a second chance”.

First off, he certainly has a point in that Microsoft did change its approach quite a bit. After all, this is the same company whose CEO once famously called linux cancer. So yes, as compared to that, they’ve changed a lot.

Now, you can argue that Microsoft only changed because it had to. Or that it hasn’t really changed all that much. Or that its past sins continue to punish developers to this day, therefore giving them plenty of currently valid reasons to hate it.

But none of that really matters. Neither its past behavior nor its current stance on open-source should matter when deciding whether to embrace the Microsoft stack. That’s because the real problem with embracing it is the Microsoft Tax you end up paying if you choose to do so. Whether because of Windows and its many issues, or the lack of real options for the tech stack, or the lack of an ecosystem to do cutting edge development, going with Microsoft means giving up something.

The operating system

Microsoft’s track record on OSes is, let’s say, a mixed bag. For every XP (good), there is a Vista (bad). Unfortunately for Microsoft, the current offering (Windows 8) is as bad or worse than anything it has ever produced (and that includes Windows ME).

Windows 8 seems to violate the principle of least surprise more frequently and more violently than any other operating system I’ve ever used (and that includes AIX, Apple DOS, MS DOS, pretty much all versions of Windows starting with 3.1, various Linuxes, multiple versions of OS X, multiple versions of iOS, and Android).

Yes, Windows 8 is chock-full of surprises. Accidentally brush your fingers on a trackpad? A random window pops up out of nowhere with no obvious means of closing it. Expect the start button that actually does useful things? tough luck. Want to launch an app, but can’t find it? you might need to know whether it’s desktop or Metro.

Individually, these may not be that bad (maybe). But collectively, the OS feels like an experiment in UX as opposed to something designed to be used on a regular basis. This is especially disappointing because its predecessor Windows 7 was really nice.

Command line / Package management

I should also mention two developer-specific issues that have historically been problematic on Windows: command line support and package management. For the command line, Windows has Cygwin, which is actually pretty good, though not a perfect replacement for the *nix Bash. And, of course, there’s Powershell, a .NET-based scripting framework.

For package management, there’s Chocolatey and Npackd. Chocolatey in particular appears promising, but is nowhere near as mature as yum, apt-get, or even homebrew.

The stack

If you’re building on Windows, you’re using .NET / C#. And while this is actually a pretty nice option, what if you want to or have to use something else? Something like Node, or Rails, or Django, or Grails, or PHP, or “whatever your favorite stack is”?

Even if you could get it to run on Windows, why would you? Does anyone you know run anything other than .NET on Windows, whether for development or production? In my experience, only JVM-based middle tiers (like Spring) seem to have decent traction on Windows. For everything else, Macs or some variant of Linux is a much more likely option.

The ecosystem

A good way to judge the viability of a particular platform is by how well it supports the current state of the art. And what is state of the art in software development today? I would propose that it’s Continuous Delivery / Deployment. The practice of continuously pushing software updates to production and everything this entails, both culturally and technically, is the most powerful forcing function our industry has seen in a long time.

These days, quite a few companies successfully practice Continuous Deployment. As a result, a rich set of tools and techniques has developed to make the automation of all the things a solved problem on *nix systems. Tools like Chef, Puppet, Ansible, Vagrant, Docker, and many others make it pretty painless to automate your infrastructure. How well do they work? Pretty well both based on my own experience (with Chef and Ansible) and the experience of many others.

What about Windows? Well, there’s Windows Azure which allows you to use a combination of TFS, Powershell, and MS Build to set up continuous delivery to it. How well does it work? I don’t know because I don’t know anyone who is actually using it. Do you?

Now, of course there are people who’re using Azure and Microsoft’s CD pipeline. And I’m certain that some (most?) of them are quite happy with it. That said, there is no question that the ecosystem around CD on *nix is orders of magnitude larger and more mature than that on Windows.

My story

I spent a large part of my career working with the Microsoft stack. In fact, at my last company, we had a large, mature product built on it, running in a pretty sophisticated Continuous Integration environment. We were using git for source control, Jenkins for CI, had a large suite of functional tests, and all deployments where fully automated using Powershell.

Then, a year and half ago, we started building a platform to support a new set of capabilities to drive the business forward. We had a set of specific and somewhat peculiar requirements to address.

First, our domain revolved around complex hierarchical documents which can be combined to produce new ones. Because a relational model is a poor fit for this kind of data, we looked for a more flexible document-based store, eventually landing on an XML database.

Now, there are certain languages which make it easier to work with XML and naturally we wanted to use such a language in the middle tier. Furthermore, we wanted to incorporate machine learning / natural language processing and most mature libraries available are either Java or Python based.

Finally, and perhaps most importantly, we wanted to run Continuous Delivery from day one. To this end, we wanted to use tools like Chef to automate provisioning and deployment.

And so, even though we already had a team well-versed in the Microsoft stack and a pretty sophisticated development / deployment system in place, our set of requirements made it very tough to go with Microsoft. It made more sense for us to replace every bit of our stack (and learn a completely new set of technologies) than to stay with Microsoft.

After a lot of debate and soul searching, we took the plunge and said goodbye to Microsoft. Not everyone was happy and it was painful initially, but it was the right thing to do and it paid off at the end. The Microsoft tax proved to be to onerous for us and I suspect that we were not unique.

You may also like:

• Continuous Delivery For the Enterprise
• Impact of Continuous Delivery Beyond Engineering
• Lipstick on a Pig is Not UX
• Agile Testing: Test case management
• Agile Testing: Dev QA collaboration

• ContinuousDelivery
• Microsoft

Did you love / hate / were unmoved by this post?
Then show your support / disgust / indifference by following me on Twitter!