.NET — Is It Really What’s Next?
Software engineering can be thought of as the tension between what’s familiar, and what’s new. I’ve been working in computers for a long time, and it’s really only a game you get into if you’re comfortable with the idea of everything changing every five minutes. Even I get a sinking feeling whenever I come across something new — I tend to close my eyes and hope it just goes away. (Note: it never does.)
.NET, right now, is 17-and-a-half years old. Practically, the work on C#, .NET, ASP+, etc started years before that, and the whole shebang was based on Java, the v1 of which dropped 24 years ago. If you ask for a bunch of CVs for a senior software engineering job in London, most of the candidates you get won’t have a professional career that long — you’d be lucky if you got people with a career longer than ten years.
Over that time, .NET has never managed to make sense to the cool kids. Don’t get me wrong, I love C# as a language, but I’m making my own point because I’ve never been cool. Netcraft’s survey of web server technologies — a set of data stretching back to 1995 — shows that IIS’s market share has hovered at best at around 30%, with (mostly) Apache taking the majority, (latterly) sharing this majority 50/50 with nginx.
Let’s mix in two assumptions. Firstly, we can assume that most desktop-targeted software are web applications. Also, mobile-targeted applications are pointed at iOS and Android, and most people doing this are either using Java/Kotlin, or Objective-C/Swift. Cross-platform strategies — if done — are now more likely to be based on React Native or (Google’s) Flutter.
The second assumption is that whatever we see pointing externally is likely the same as what is being used internally. It doesn’t make sense to skill up two teams using disparate platforms for internal and external consumption. Netcraft’s interactive query tool — “What’s the site running?” can be used to see what an organisation is likely to be be using internally. HSBC UK, for example, looks like it’s running systems based on IBM HTTP Server on Linux. It may therefore be safe to say that when building out internal tools, the HSBC teams are not using Microsoft .NET.
Take that to a conclusion though — given that we know only one-third (at best) of webservers are running .NET code, we can say that most software is written on anything other than .NET.
The problem here is that any time over the past 18 years, I could have written the exact same article as that. No one has ever been falling over themselves to write on and deliver on Windows. It’s always been a simple, low-risk option, but it’s never been sexy cool.
Choosing a technology stack for a software project is a tricky thing, because no matter what you base a project on, an asset today becomes a liability tomorrow. Whatever you choose today will dwindle away in importance and the rot will set in. Some technologies seem evergreen — we’re going to be launching manned missions to other star systems in the year 3010 and the ship’s systems will be strung together with JavaScript and HTTPS — but it’s always going to be true that all software projects follow a curve down from “cool” to “regret” over the long-term, if for no other reason than evolution of architectural approaches make it so.
What has changed over the past ten years or so are the “composition model” of these different tools. There is now a greater focus on the “pick and mix” approach of composing solutions. If you choose the right parts, you can’t go far wrong, and we’re now getting so good at building components that you can almost choose these things at random and end up with a workable stack.
To test this out, create a list of operating systems, web servers, databases, languages, web framework, testing frameworks, containerisation tools, and deployment tools. Pick something from random from each list and imagine building an application on that stack. You may not know how to do it personally, but whatever you did pick would a) likely work, and b) not be that bad from now into at least the medium term. Go back ten years and try that exercise and it’s unlikely it would work as well.
The challenge that Microsoft has now with .NET is that this is the world that it plays in. Today, why would anyone choose to deploy on Windows, write in C#, code against .NET, store data in SQL Server, build on ASP.NET Core, or deploy on Azure? There are going to be good reasons for doing any of those things, but they’re not going to be great reasons.
Microsoft has a difficult job to do now. Microsoft has to get the .NET Framework 4, which will be slooooly going away over .NET 5. The message is already out there that it’s not a great idea to be building new solutions on the .NET Framework and that new projects should be thinking long and hard about going to .NET Core. Coming back to that last point — why? If you have to change anyway, if you’re a developer or a shop that’s longer in the tooth, is now the time to wean yourself off of Microsoft entirely?
