Disclaimer: Microsoft is a large and heterogeneous company and these comments will not necessarily apply to all of the organisation.
I’ve just read a blog post by a Microsoft Software Engineer that represents what I believe is the fundamental problem with how Microsoft views the developers who use their tools and APIs. Here are the two key quotes:
“We sit around the table designing APIs, and for the most part unless we have time to actually think through the extensibility/usage scenarios and ensure they’re safe or at least make some sense, and have time to actually test those scenarios, we seal those bad boys off to protect users from themselves.”
“Hmmm, I guess I can’t complain too much about my tamper resistant controller now, since when it comes to API design, I’m in the the “seal it” camp. Just like XBOX support doesn’t have the bandwidth to deal with calls from a bunch of gamer geeks wondering why their “tricked out” custom controller jobs are producing smoke and getting them killed in Halo, we in DevDiv creating glorious frameworks don’t have time to participate in long forum threads attempting to help debug crazy Rube Goldberg extensibility scenarios that we never dreamed of (they’re trying to do whaaat with our APIs??).”
What paternalistic crap. I’ll tell you whaaat we’re trying to do with your APIs. Our jobs, delivering value to customers with your platform. I’m sorry you think living with whatever you imagined the use cases of your API to be more important than achieving usable solutions for customers. Having people put your technologies to uses you didn’t anticipate is par for the course in this industry. Hell, for frameworks it should be flat out expected.
The reason people need to come up with “crazy Rube Goldberg extensibility scenarios” is that far too many Microsoft frameworks and products simply don’t support the extensibility points necessary to make them work in real world scenarios. For instance it’s very telling that ASP.NET MVC (a shining example that Microsoft can build solid, extensible systems when it chooses to) had to introduce abstractions for key ASP.NET classes rather than be able to use anything existing in the ASP.NET stack. I shouldn’t have to write an abstraction layer around parts of the BCL just to be able to do TDD with them. This additional effort on my part to apply good practice to my development is a failure of the API design.
The underlying impression is that developers on Microsoft platforms are idiots who must be prevented from going anywhere near anything difficult. If this is true I submit that it is a problem of Microsoft’s makings. Far too much of Microsoft’s tooling and frameworks actively makes it easy to produce software very, very badly. This may demo well but the results cannot be effectively or efficiently maintained or extended. With this much pressure to do things badly it’s no wonder than the standards for the average .NET developer are so depressingly low compared to other platforms.
What really depresses me if there’s a huge amount of potential in the platform if you can get past this. LINQ-to-Objects is something I can’t live without (LINQ-to-SQL not so much). There are a lot of open source projects out there if you look that provide extraordinary value. You can build scalable, maintainable enterprise grade solutions on the .NET platform. But you’ll never do that with drag and drop.
Yes, I am aware this post pretty much kills any chance I have of ever working for Microsoft :)