Why (pre-Satya) Microsoft was stupid

Go back

I have 3 years of professional experience working with Microsoft stacks.

I've been programmer since I was 12 (making wacky little web games).

My professional opinion of Microsoft is this:

While, they pioneer a lot of robust (and even daring) technologies, because of their tendency to trailblaze with little foresight, they often end up creating overengineered solutions that are only designed that way to follow "industry standards" (which they are also largely responsible for setting...).

Overengineering causes poor designs that add layer upon layer of complexity to an otherwise simple concept. They tend to do this because they focus really hard on Design Patterns (many of which are good, when used properly, but when misused/abused they lead to overengineering and quickly; for example Dependency Injection, which is not one of the Gang of Four's design patterns in and of itself...)

Microsoft is notorious for this, and I will use this webpage to list off great examples of it:

The standard SMTP Client - This bad boy is so terrible they just stopped trying to support it altogether. For reference it is responsible for lots of undisposed connections, protocol failures and other things. While I've never cracked open the source code, the only good reason I can think of that an SMTP client would fail to keep up to date with protocol standards (when the software itself is supported by an absolute titan like Microsoft) is because it was hard to maintain. Software is hard to maintain when its poorly designed, which overengineering leads to; poor design.
Unity Framework - I don't know why, but Microsoft (and their dogmatic fanboys) have this huge hard on for dependency injection. Dependency injection is basically an extension of the Inversion of Control design pattern. The main "advantage" of dependency injection is decoupling classes from their dependencies.On the other hand it comes with several drawbacks. You instantiate and populate objects all the time, why the hell would you need a library that reads from a separate config file to then do the exact same thing for you? It also uses metaprogramming to achieve this (which is why it makes the code/stack traces harder to follow, it creates types that literally are not in your code or the unity framework dll).
The large adoption of XML over JSON - I blame Microsoft for this because XML is used for pretty much every configuration possible, and because of this they keep introducing more and more and more tools to deal with XML.. they arguably have the best XML parsers (I mean, their XML parsers literally generate class libraries...). The only value of XML is the fact that there are systems that use XML. And unfortunately, some of those systems are actually really important, so we still use it today. Which, is ironically the exact same reason a lot of older developers don't believe in the block chain lmfao. XML has no real value, it's longer than JSON and does not translate directly to objects, which JSON does... because it was meant to from the beginning (ironically, this object impedance mismatch is also why I'm not a fan of SQL databases, which are just another unnecessary but now-necessary evil of web design). You can also represent the exact same data in XML multiple ways, for example an array. This little rant leads me to
WCF (and SOAP) - WCF is basically supposed to make the process of writing RPC code easier. Supposed to. Instead what you often end up with is a bunch of crap buried in a hard to read XML config file, the problem with XML configs are, a value can either be an attribute, or a child node. So if I say "Oh just change the TargetURL property" you have to then ask me "Is that in a child node or an attribute?". XML tried to be useful by coming with schemas (XSD), which led to the advent of SOAP and generation of SOAP clients. The problem with requiring schemas to interact with a service (WSDL) is, if at any time the service contract (e.g. the data types the web service publicly exposes) changes... Are you ready for this?... all client applications break. Ba dum tss (now, while this is actually pretty useful in practice, generating SOAP clients/WSDLs is incredibly difficult, and therefore there are few libraries that do this, not to mention SOAP only supports one data type... XML. The biggest problem with SOAP is that all the protocol really does is reinvent HTTP ontop of HTTP... it didn't streamline development by coming with any meaningfully imposed standards/restrictions. All of the design choices made when SOAP came to be just seem incredibly arbitrary, but then again, that's pretty on-brand because the same could be said about XML/XSD (and the entire ecosystem surrounding XML... boy is it expansive)
And the list goes on... just you wait, this is just off the top of my head

Why (pre-Satya1) Microsoft was stupid

Why (pre-Satya¹) Microsoft was stupid