The Microsoft developer ecosystem has become too... asynchronous

posted by Jeff | Tuesday, December 26, 2017, 7:38 PM | comments: 0

If there has been any constant in my professional life (once I got out of the broadcast world), it has been Microsoft. After HTML and CSS, and a little Perl, I was introduced to Active Server Pages at my first real Web job, and the "evil empire" has been with me ever since. I admired it so much that I worked there for a couple of years, and sometimes regret leaving. The change at the company has been extraordinary, and I don't think we've ever had so many fun tools to play with as we do now. Unfortunately, it's not at all consistent, as the sprawling set of tools suffer from a synchronicity problem. If I sound critical, yes, I am, but stay with me for a moment.

In my two years at Microsoft, I happened to be there for a massive, coordinated release. In 2010, we saw the simultaneous release of .NET v4, Visual Studio 2010, MVC 2 and a bunch of other stuff I don't remember (but I'm sure I still have the T-shirt somewhere). There also happened to be a massive release party outdoors for all of DevDiv, which at the time I'm pretty sure involved more than 10,000 people. It was a pretty big deal, after a long beta period. I was working on the MSDN forums and profiles at the time, and we were also spinning up the reputation system (scoring game) that worked across the various properties and is still around today. We were pretty bleeding edge, and an early internal customer of Azure.

This was, in every way, a classic "big bang" release, with a lot of bits shipping all at once. The company famously handed out "ship it" plaques to people for big events like this, which for us was a little weird since we were deploying new stuff every few weeks. I still have mine, with a single tile filled for something having to do with MSDN that, frankly, was just a part of our typical cycle. The big bang was pretty normal, as anyone looking from the outside in could imagine. New versions of Windows, Office and indeed Visual Studio, were annual affairs at best, with long beta periods before the release. It was a normal that felt a little antiquated for anyone working on a web-based product.

But the nice thing about it was that all of that new shiny stuff hit at once, and if you were playing along during the beta period, you could probably start using it all on the first day. Having maintained POP Forums even in those days, this was usually how I would roll, with my own releases pretty close to those big product releases (even though I didn't start hosting on the late CodePlex and later Github until late in 2010).

Those days are long gone. The .NET Framework was rebooted as Core in a completely open source manner. That reboot took a couple of painful years, and the second version took more than a year. Visual Studio seems like it's modular enough now that the frequent updates will largely replace wholesale version changes. Now we have Azure and its huge collection of cloud services, along with a bunch of SDK's, to build and deploy stuff. ALM is easily handled via Visual Studio Team Services (VSTS), handling all of the build and release tasks, work tracking and such, without having to install anything yourself. It's a vastly different world, but it comes at a price.

In the new world, the lack of big bang moments means that new stuff comes out, and the various components don't work with each other. For example, a couple of weeks ago at work, we were excited to bring the .NET Framework version up to the latest bits, and only six week after it was released! My enthusiasm was dashed when the project wouldn't build in VSTS, because their build images didn't have the new framework on them. I love the changes in ASP.NET Core, but none of my sites run on it (after two years) because they still haven't shipped a new version of SignalR (the websockets signaling framework) to go along with it. That's a key thing for me. Then tonight I thought I'd mess around with my forum project and move the background processing (optionally) to Azure Functions. But nope, the SDK doesn't work with Core, or maybe not Core 2.0. I'm not even sure yet.

Nothing seems to work together, at the same time, and it has become a hinderance to using any of it. In a world where we're relying more on distributed architecture (often adding unnecessary complexity, but that's another topic), you'd think that this would be less of an issue, but it seems to be getting worse instead of better.

I admit that I might be overly critical. One could argue that the new world is better because it allows for more frequent innovation, better stuff coming to market faster. That might generally be true, but if it doesn't work on the latest framework versions, that's a big issue. Let's be clear, the frameworks are the slowest moving parts, and rightfully so because your foundation should not be a moving target. They also have long beta periods, so when they do ship, it's not really a surprise to anyone. So when an SDK doesn't work on the the latest framework, or the cloud tools can't build on it, or a peripheral component hasn't been updated after several years, it's frustrating.

It's pretty weird that (if you don't count my blog, and I wouldn't) I don't have anything written for .NET Core in production. I was such a bleeding edge kind of guy back in the day. I think that's partly just my change in priorities, which in my day job is shipping stuff that works today, and in my hobbies is being perfectly OK with the status quo. But I want to be using the latest stuff, I just don't have the will to overcome what isn't current.


Comments

No comments yet.


Post your comment: