Now that the team has long since made the transition to .NET, we have started doing new development in C# because that is what the team favors now. We still maintain that legacy app in VB.NET because, frankly, there simply isn’t any tangible benefit to outweigh the cost of porting the app. I can’t sell “I need x months of development budget and at the end the app will be the same (perhaps with some bugs introduced by the port), but in a different language”. In the end the most important point was that it simply doesn’t matter. That project has gone forward for years, used third party tools and libraries and never has the VB.NET language created anything more than a trivial issue here and there.

So ultimately, I don’t regret the decision. Not because I think VB.NET was necessarily the right decision, but more because in retrospect the decision didn’t matter as much as I thought going into it. The team is now proficient in both languages, supports products in each of them and our legacy application continues to be a successful project. My advice to someone making the decision today would be: Defer to your team, a happy development team is a productive one.

I do think you are forgetting a key driver in your evaluation — industry and developer community engagement. This may have been debatable in 2009 (no, it really wasn’t) but it’s crystal clear now… the community prefers C# — if you don’t agree look around and packages, open source APIs, etc and you’ll find C# is language under the hood. And a majority of 3rd party components that enterprise developers find themselves integrating into their systems provide better support (examples, native SDKs, etc) in C#.

Forgetting that, I don’t see how you reviewed the “Facts, et al” and came to the decision of VB.NET. The only significant issue I could see holding you back was the legacy VB support — you were worried about converting VB6 to .NET. You could have either converted it to VB.NET as (legacy) and then used C# as the Go Forward — or you could have just converted it to C# (from VB6) — if it can be converted to VB.NET then it can be converted to C#. But honestly I’m not sure conversion for the sake of conversion was a good idea either.

Regarding developer productivity. It seems you missed a perfect opportunity to challenge your team to learn something new and improve themselves. Instead you gave them an easier out so they could remain comfortable. I agree, speed to productivity is a concern so I feel your pain on that, but I also think you preferred a short-term concern as opposed to looking at the long-term growth and strength of your team.

IMO – Based on the findings you present here (except for some dead wrong comparison of C#/VB.NET roadmap) you should have chosen C#.

Do you regret your decision? What has happened since 2009?

With the introduction of C# and VB.NET the difference is almost exclusively defined by sugar coating. After coding many apps using both languages I still can’t figure out for the life of me which one is more productive or better. I really don’t care anymore. I use whatever is needed. I think every experienced programmer is multilangual to begin with…

Now a different subject: C# is for the smart ones, VB.net is for others.
Really? A few facts based on my experiance:
1) Anyone can learn any programming language. The talented one will learn the real/full potential of both languages faster.
2) The smart ones will eventually bring their code to a higher level. Think of best practices, design patterns and whatnot. Both C# and VB.NET will give you basically the same options these days.
3) The “power user” roadmap for C# only pays off if the customer wants to pay for it. Rarely do they know what that means and they don’t care either.

To conlude:
- if you find a programmer who can’t handle one of these languages well then you’ll know you have a slightly lesser talented programmer.
- If you wish to use “power user” features then your business model should be set for this type of quality – meaning customers who want to pay extra is hard. Is your company ready for this?

However, for existing projects of any size in VB.NET I still wouldn’t recommend porting them to C#. The payoff doesn’t seem like it would be worth the effort.