Why I have been in love with C# and .NET for more than 15 years

C# and .NET, a fully managed development ecosystem?

TL; DR: I’m in love with C# and .NET because it is an opinionated development ecosystem that lets you focus on the purpose of the software you are building and the people it serves rather than on the technologies you have to use to build it. It is the exact same reason that makes me always prefer fully-managed serverless services rather than self-managed middleware or hardware solutions. Let’s people who know do their magic and focus on what you are good at!

I have built this perspective across the years but I’ve been able to concretize it only very recently. Once again, I was asked why I have sticked to C# over the years while it seems a dead-end. So, I took the time to reflect on this question.

First and foremost, let’s be clear: C# and .NET are not a dead-end! The State of the Developer Nation Q1 2022 survey highlights there are 10M active C# developers around the globe. A growth of 2.2M in the last 6 months. So, it is hardly a dying community. Rewriting the .NET runtime as a truly cross-platform runtime running on Windows, Linux and MacOS and on x86 or ARM chips as well as open sourcing it as been a game changer to renew the attention of developers and enterprises for .NET.

Second, this opinion is based on my personal experience over the last 15 years. Let me give you a bit context so that you understand where I come from.

How it has started

I’ve started to learn C# back in 2006 during the last year of my PhD thesis preparation. I was developing pen-based software incorporating handwriting recognition capabilities with my team peers. The only available pen-based consumer platform was Windows XP Tablet PC edition. It came with a nice Ink API that we could leverage to get the stroke data and process them with our algorithms.

This Ink API was available through C# and .NET Framework. The API was convenient and we could easily hook to events to integrate our processing. Visual Studio 2005 was already there to make the development straightforward.

In 2007, the research team leaders created a startup to productize the results of their work and I jumped into it all focused on developing pen-based software for field workers. We were working with early adopter customers who helped us define the product. C#, .NET and Visual Studio was comfortable for us. We didn’t have to think about which tools and frameworks to use. The .NET Framework API, the Ink API and .NET WinForms, that was it. No waste of time on evaluating technologies.

Unfortunately, the 2008 financial crisis hit us and despite all our efforts at the end of 2009, our CEO started laying off the team progressively. At that time, few companies were keen to try new technologies and change the way their field workers operate during a crisis. He tried to delay the inevitable but in early 2010 that was it. I was one the last to quit the boat.

During this period, our only focus was to build great handwriting recognition algorithms and great pen-based user experience. We never had to care about which framework or which third party libraries to use. We just trusted what came with .NET Framework. Our failure has never been related to our choice of using C# and .NET Framework.

How it has continued

After this worth but exhausting experience, I’ve decided to join a System Integrator. I had the feeling I was missing some best practices to really be an efficient developer. I wanted to join large development teams with experienced tech leaders to learn from them.

At that time (2010), I discovered that the development world was roughly divided in two: Java developers and .NET developers. Non-conformists were PHP developers. There was a kind of flame war between these two communities: Java developers were the superheroes of the open source world while .NET developers were the villains of the proprietary world. I have experienced very tough discussion between colleagues just because they were not from the same development community. Completely lunar but, unfortunately, this kind of flame war discussions still occurs nowadays with the new trendy topics.

I tried to stay away of these sterile battles. One thing I had noticed is that Java community was a bit ahead of time compared to the .NET community regarding best practices such as ORM, unit testing, end-to-end testing, continuous integration, continuous release and deployment. I decided to learn from the Java community their best practices and import them into the .NET world. I had the chance to join a team of Java experts who were advocating customers for those best practices under Philippe Ensarguet’s leadership. He offered me the opportunity to advocate for those best practices for our .NET customers and grow a team of .NET experts.

As usual, .NET ecosystem was not ahead of time with promoting these practices but did a good job at catching up. They built their own unit testing framework for .NET and supporting NUnit and xUnit, .NET open source alternatives. They accelerated the development of Team Foundation Server, their CI/CD platform, which will become Visual Studio Team Services and later Azure DevOps.

Sometimes, they had hard times like with Entity Framework. The first version was an absolute catastrophe leading to a ‘vote of no confidence’ from the community. But they kept pushing and solved all the issues, improved performance and got a wide adoption.

During this period, I realized that .NET was not a pathfinder ecosystem. The .NET ecosystem was always a step behind other development ecosystems but good things always ended into the .NET Framework. You could also expect that ephemeral trends wouldn’t fit into it. You just had to be patient and continue to deliver values for your customers and your end users. I have learnt to spot new trends into other development communities like the rise of Git source control and to be on the edge to advocate them when they find their ways into the .NET development tooling.

I can also testify that I’m not the only one to love this. Enterprises also love this. If they select .NET as their development stack and Windows as their execution platform, they know they probably won’t have the bleeding edge technologies but they will get mature enough technologies that will be supported for a very long period. For example, .NET Framework 2.0 has been released in February 2006. Its Service Pack 2 version will be supported until January 2029 for customers who have installed .NET Framework 3.5 Service Pack as this version is built on top of .NET Framework 2.0 SP2. Kind of crazy support period isn’t it?

Enterprises love long support period but it has a major drawback in my opinion, it slows down innovation both on Enterprises side and .NET side.

How it changed for the best

A major pivot happens in the .NET ecosystem November 12th, 2014. .NET Core has been announced. It was described as a complete rewrite of the .NET runtime in the open on GitHub and under the umbrella of the .NET Foundation. The plan was to make it fully cross platform.

At that time, I think most of the IT industry didn’t notice the importance this announcement would have in the future. On June 27th, 2016, .NET Core 1.0 was announced. This first version was all about modern web apps and microservices development. Exit desktop apps. They made strong choice to release a first version that was aligned to the new trend: Cloud Computing. 7 years after the beginning of this crazy adventure of rewriting the whole runtime, .NET 6 has been announced on November 8th, 2021. It is a mature Long-Term Support version that is production ready for hosting web app and microservices on Linux as well as developing desktop and mobile apps.

Still nowadays, I still meet a lot of developers or customers who don’t know or even don’t understand that .NET now really run Windows, Linux and MacOS with x86 and ARM chips. However, .NET 6 empowers you to run your applications where you want.

In my case, my favorite compute engine is AWS Lambda. I’m totally fond of it. As I have did during all my career, I’m fine to deal with its limitations (i.e. cold start and 15min max execution duration) because it allows me to run my .NET 6 code in a fully serverless environments on ARM chips. As for .NET, I’m pleased to rely on people who know how to do their magic!

Once again, the .NET ecosystem has been able to integrate the best things from other development stacks. They have understood the benefits of working in the open with the community and of having a truly cross platform runtime. They embedded those concepts for the best.

Conclusion

I’m a business and consumer software developer at heart. I’m not a technology software developer. What I love when I’m developing software is thinking about the impact it will have on the end users, how it will empower them to achieve their goals. I’m not a big fan of spending a lot of time to choose the right logging library, the right ORM, the right authentication library, etc. I’m ok to deal with some caveats as long as I know they will be fixed in the long run.

C# and .NET are all about this philosophy. I see them as a fully managed development ecosystem avoiding me the heavy burden to select all the components I need to build my application. Like a fully managed Cloud Computing services, the deal is that I need to agree with the limitations of the ecosystem. It is no different than agreeing with the service limits of AWS Lambda.