Is .NET in Trouble? (Belated Thoughts from Connect 2015)

by Mike-EEE

TL;DR: VOTE! ^

This post exists to build consensus in the Microsoft developer community around the idea of a ubiquitous .NET client application development model.  Show your support by voting for this idea here:

“But Connect 2015 was over Two Weeks Ago!” ^

Developers.win is a personal passion project of mine, so it is at the mercy of my schedule, whenever I can find time for it.  Case in point, I am just now getting to write this post, which is essentially my thoughts on Connect 2015, an event that occurred over two weeks ago.  Of course, schedule and time are relative, as this post is actually driven by great conversations held in the Disqus comments in Microsoft News.  Somehow, I found the time to have those, and in doing so I kept thinking to myself, “why not make a blog post over this?”  So, I put it on my task list for when I can get to it, and here we are.

(For those who are interested for the discussions inspiring this post, check out this article and this article , skipping straight to the comments — there the true content of any worthy article posted these days truly lies.)

The Problem ^

We have already seen the error in the technical advice given by the Visual Studio group in regards to its “answer” to Silverlight 6.  Unfortunately, this same “strategic” thinking (for whatever reason) still permeates Microsoft today and was on full display during Connect 2015.

While on stage during Connect 2015, Scott Hanselman, Scott Guthrie, and Anders Hejlsberg all happily endorsed Visual Studio solutions featuring a JavaScript (and TypeScript) client running on top of a .NET back end.  This is (and really has been) considered the “new” de-facto standard for any “.NET development” for the new world of ASP.NET 5 and the new .NET Core (or is that Core .NET?  I always get those confused… let me go look it up again to make sure…).

Not many .NET developers have questioned this approach, which I find disturbing from a .NET perspective and hence the driving force behind this article.  To be sure, Microsoft is reaching out its olive branch to non-.NET (read: Node.js) developers to provide offerings to entice them and bring them into their platforms, most notably Azure and the new Visual Studio Team Services, which were clearly the star of the Connect 2015 show.

My guess is that .NET developers — like all developers — have been mesmerized (dumbfounded, even) by Microsoft’s new approach and shocking shift to embracing open source and cross-platform technologies.  However, .NET developers have not really given much thought to HOW (or in particular the strategy) Microsoft is doing so.

Microsoft should indeed be reaching out and enticing non-MSFT developers into its technologies and platforms, but not at the expense of .NET and its traditional application development offerings.

Building a Culture of Excellence (Experts) over Mediocrity (Generalists) ^

I’m going to take a step back and try to explore the root of the problem here as I see it.  I am hoping that once the root is explored, the flaw in Microsoft’s current application development endorsement will be easier to see.

Let’s start with our good friend Malcolm Gladwell (he IS your good friend, right?) and his 10,000 hour rule.  Here is a good article that even explains how it is completely used wrong and misused by everyone.  For the purposes of this article, I simply want to use the 10,000 hour metric as a way to identify an “expert” within a system, or more specifically an organization.

An expert within a system is more cost effective within an organization as they have a valuable combination of talent and experience.  They understand a particular system (domain) and its idiosyncrasies.  They know all the tricks, but more importantly, since they also have the talent, they are constantly innovating within their field of expertise.  From a business perspective, experts are cost effective to an organization as their skill set can be leveraged with more efficiency than those of generalists (non-experts).  This is because experts typically can get a job done faster and at a higher quality than generalists.

Generalists (non-experts) are more expensive to an organization as they do not completely understand the problem domain as well as an expert.  In software development, this leads to lower quality product (code) as the product tends to have more defects due to poorer design (deficient knowledge).  Generalists do not fully understand the idiosyncrasies of the system, and this leads to inefficient use of the system to yield desired results.

Since generalists are not as knowledgeable about a system, they take longer to work with it.  In software development, this manifests in inaccurate estimates and longer development times for tasks that could (typically) be better-designed and develop by an expert — with a (typically) lower defect count.

Then there is the issue of financial cost.  Let’s say that I am a business owner that wants an app built.  If I am presented with the option of hiring two generalists (lower rate) or one expert (higher rate), I will be tempted to choose the expert as that is less resources spent on management (one resource rather than two), while getting a higher quality code base (and resulting product) that is developed faster (high system knowledge) than a generalist (general system knowledge).

“Full-Stack” “Expert” ^

This (hopefully) brings us back to the main point of the discussion.  I see a lot of job listings out there for a “full-stack” developer, and what these listings really mean is that they want a developer that can code from user interface all the way to the database.  This, of course, requires knowledge in different technologies, and these listings seem to pride themselves on naming as many technologies as possible.  Unless they land a very rare developer who has spent 10,000 hours on each of those technologies, what the company ultimately ends up with is a  generalist that can “wear many hats” and is a “jack of all trades” (and indeed, is a master of none).

Now, I will admit that I get a case of schadenfreude when I see these requirements as I know what sort of dumpster fire is currently sitting in their source control.  The reason (or one of many reasons) why their code is always on fire (and they are constantly firing and hiring a new fire marshal) is that these organizations continue to seek and hire generalists to build upon on their solutions that span these many different technologies.  This is a very messy and error-prone way of handling solution development, and anyone who has had to endure such a scenario — since there are always so many of these listings we can assume that a large majority of the developer population has been recycled through one or two of these — can attest to this madness.

Now consider a “full stack” solution where the same web-hosted (ubiquitous) technology is used from user interface to database.  If you are a .NET developer, you will have to close your eyes and imagine a world like this at the present moment.  However, if you are lucky enough to be a Node.js developer, you don’t have to do much imagining, as you are living it.

As a Node.js developer, you enjoy access to a viable JavaScript-based API for client-side development, service/service-based development, and database-based development (full disclosure: I am not a Node.js developer, I just like to Google about it when I am writing a blog article about it).  As a result, every second spent within a Node.js solution built in this system is one second closer to becoming a 10,000-hour Node.js/JavaScript/TypeScript expert.

Conversely, as a .NET “web” developer, you have to spend your time between C#/.NET on the server side, T-SQL on the database (unless you use an O/R mapping solution like EntityFramework — or gasp use T-SQL right in your C#: YUCK!), and — SURPRISE! — Node.js (and/or Angular.js) on the client-side.  This is because — as we saw on full display in Connect 2015 — Microsoft is not offering a web client development solution, but is inexplicably leaning on Google to provide it for them.  Spending 10,000 hours across these two (or three) different technology offerings does not an expert make in a single one of these areas.

Showcasing the difference between .NET and Node.js web development after 10,000 of development time.

Showcasing the difference between .NET and JavaScript (Node.js) web development after 10,000 hours of development time.

As a result, Node.js application development is successfully producing “full-stack” experts in Node.js and JavaScript, whereas .NET application development is producing “full-stack” generalists in .NET (and maybe even Sql Server) and Node.js.

Flocking to Node.js ^

The additional problem here is obviously that I am not alone in seeing this, and companies/organizations are catching on to this as well.  You are starting to see chatter online in developers and their organizations realize the benefits of having a single technology and language used “full stack” from client to database.  Why use .NET when it gets in the way and is ultimately not like the JavaScript that is used in the client?  Why use .NET when you can’t use that fancy new ExceptionReporter (or is that exceptionReporter? ha ha — different casing in JavaScript, right… RIGHT?!) you made in JavaScript, but can use it within a Node.js server boundary?

Ultimately, as a .NET web developer that Microsoft is endorsing in Connect 2015, you are having to build and maintain two different code bases (.NET and JavaScript/TypeScript), and that is ultimately expensive both from a technical and human resource point of view.  I hope this is obvious why:

  • Each code base has its own set of defects.
  • Each code base has its own set of class definitions and concerns (that may or may not overlap each other).
  • Each code base requires a skill set to build and maintain, which may or may not be possible to address with one person.
    • Even if one person can manage each code base, they may not be an expert in both of them. This affects quality (and therefore Total Cost of Ownership).

Stemming the Flow ^

So what to do?  Developers.win is committed to building consensus around the concept of a ubiquitous .NET client application development model within Microsoft and its community of developers.  The only power we have as Microsoft developers is to use UserVoice to show that we want this addressed.  Microsoft does use and pay attention to its UserVoice, so please, take a second to vote with the pretty vote button below.  Also, please feel free to leave a comment as well, as this is my baby and I am very interested in hearing what other developers think about it.  Thank you for your consideration and support!

  • Peter Wone

    While I agree with your larger observation that a jack of all trades is a master of none, I think you draw a long bow. MVC Web API, Linq2Sql and SQL Server is a sublime combination. Most of my API methods are half a dozen lines of code.
    At the other end, it is trivial to parse data shipped as JSON, and Typescript brings order to the JavaScript madness. I’m not a big fan of Angular, but there are better frameworks like Durandal and Aurelia.
    I find that after thirty years I’m highly suspicious of programming fads. The beauty of Durandal was that it was an organisation of the existing: Knockout, Require, jQuery, Sammy. So there wasn’t much of a learning curve, because everyone was already au fait with most of the pieces.
    The successor, Aurelia, is similarly minimalist, but depends on language improvement in ES6/7 and clever use of fallback technologies to get it to run on today’s browsers. The main point is that familiarity with Typescript is a running start, and as browsers start to directly implement ES7 the only thing that will change is the load times.

    • Thanks for your feedback, Peter. I am surprised I haven’t gotten more until now. 🙂 I am indeed a huge fan of Aurelia and what Rob is doing over there (and really since Caliburn in WPF/Silverlight).

      The core issue here is that once you introduce TypeScript/JavaScript into a .NET solution you run into a problem of efficiency (that is, higher TCO) and technical integrity (by breaking DRY/encapsulation) and I am not sure that this is drawing a long bow at all. As such, I am glad to hear your methods are half a dozen lines. Congratulations. 🙂 But, if I am not mistaken, you still need things such as error handling and instrumentation there, correct? You also need this “on the other end” once you wire in the TypeScript/JavaScript, correct? If you do, and you are re-writing these components, you are essentially breaking DRY and encapsulation. More here: http://blog.developers.win/2015/10/the-broken-burned-bridge/

      Even if it is just a “few lines” at a time, it is still breaking best practices, which are there to maximize efficiency and reduce TCO (and I am sure you are aware of how these seemingly small things ultimately add to time and cost).

      Now, my 15 years of experience is only half of your 30 (and I am starting to become like you — weary of new tech), so I am definitely interested in discussion here to make sure that I have this right. Please feel free to check my logic and provide any feedback that you can. In the meantime, please feel free to vote (which is really ultimately the best we can do here to help improve MSFT here). Thank you for any support and continued dialogue!

      • Peter Wone

        [big sigh] Yes, I know. I’ve spent the last five years deflating JS enthusiasts extolling their latest strides of tech by saying “Congratulations, you’ve almost caught up to where Silverlight was five years ago”
        Silverlight RIA had… everything. And that was what killed it. If you actually produce a robust, comprehensive end-to-end system with complete tooling support, you are finished. There’s nothing more to say on the subject. No more headlines. No eagerly awaited releases. The next version won’t be better.
        If you want a metaphor, Microsoft’s henchmen shot Bond the moment they saw him snooping. The movie was over before the opening credits.
        JS by contrast has been so bad (yet just good enough to survive) for so long that it is widely understood and widely used. with ES7 it would be in peril of completion, but for the ongoing browser wars.
        Incompatibility and the endlessly evolving workarounds will provide the activity and novelty required to prevent the amnesia of stagnation.

  • Pingback: Azure, Xamarin, and … a Ubiquitous .NET? | Azure Development Community()