There is no shortage of discussion or flame wars weighing the relative merits of the various Microsoft .NET programming languages, nor is there an outcry for another opinion on the subject. This article will instead discuss the process of making a sound business decision on a controversial issue without inciting mutiny among the developers. More importantly, I’ll revisit some of the key considerations in that decision through the razor sharp focus of hindsight. It is my hope that my experiences from the trenches will provide guidance to software development managers who have not yet made the jump to .NET, are bootstrapping a new shop, or are considering a switch from another platform.
It’s been just over six years since I managed the transition of my development team to Microsoft’s .NET platform and made the call, for better or worse, to standardize on VB.NET. As a developer myself, I was keenly aware of the how the programming language of a software development shop defines its culture and similarly shapes the professional identity of many programmers. The polemic among developers created a real risk of breaking down the team dynamic through second-guessing and deflated morale regardless of my choice. As is the case with implementing any politically sensitive change, the prudent course of action was to aggressively seek buy-in by actively soliciting input of each team member, remaining visibly objective, and maximizing the transparency of the issues that factored into the final decision. Despite the lack of unanimity requiring over 30% of the team to acquiesce on this hot-button standardization issue, the team dynamic remained strong after my final decision.
The Players
Although the list of languages that are currently supported on the .NET framework is more diverse than most would probably imagine, the options were far more limited back in 2003.
C#.NET: A hybrid of C and Java that attempted to lure defectors from the Java camp to the .NET platform. It also provides an easy transition for C++ refugees who are sick of the annoyances of manual memory management and having 9 incompatible ways to implement a simple string.
J#.NET: Most of the quirks of Java and none of the cross-platform support and about as useful as non-alcoholic beer. Enables developers to pretend they still hate Microsoft, but participate in their market share. Also allows Microsoft to pretend that C# wasn’t a blatant attempt to crush the upstart Java language that threatened to weaken their dominance of the OS market. The technology pundits have moved on to other issues enough for Microsoft to silently drop support for J# from Visual Studio.
VB.NET: The next generation of the popular Visual Basic language, all grown up and fully OOP capable. It is unfortunate that Microsoft didn’t take this opportunity to rename the language to remove the stigma associated with programmers using this language that only resembles its forebears in its verbosity. I assume they kept the name to provide an unambiguous upgrade path for the unwashed masses of VB6 programmers many of which ironically and belligerently dug in their heels and refused to upgrade.
C++.NET: For a while I assumed that I must have been missing something with respect to C++.NET. The juxtaposition of the venerable I’ll-roll-my-own-thank-you-very-much C++ and the don’t-worry-your-pretty-little-head-about-cleaning-up-that-memory .NET framework felt even more awkward than “Java.NET.” I took a course to absolve me of my silly notions, but only managed to reinforce them. C++.NET is neither fish nor fowl. It is like a halfway house for recovering masochist programmers who really want to like automated garbage collection, but want to take it one day at a time. Just one more hit of STL, I promise I’ll quit tomorrow! In one of the rare parallels with the VB camp, many of the Microsoft Visual C++ developers found little motivation to abandon Visual Studio 6.
The Contenders
Let’s face it. Aside from C#, VB.NET, and their ugly cousin C++.NET, none of the remaining .NET languages were used for much more than Microsoft demos to prove that they wanted to support open standards. This was even truer back in 2003 when I was weighing the options. The team divided itself naturally into a C# and VB.NET camp and no one even hinted at seriously considering a third option.
The Process
It is extremely important when soliciting input from employees to be very clear about how the final decision is going to be made, especially when it is not the purely democratic process that they might otherwise assume. Recognizing this, I was careful to communicate that while everyone’s input was valued and would be carefully considered, I’d be making the final decision based on both the advice of the team and the interests of the business. I promised complete transparency on my decision and a chance to appeal it on factual, but not subjective grounds. As it happened, no such appeals were proffered. The C# proponents were slightly disappointed, but were also thankfully supportive the decision to go with VB.NET.
My solicitation for input included the following:
- Provide as many supporting arguments for your preference as apply to our environment.
- Arguments based on business objectives (reduced cost, greater efficiency) will be weighed more heavily.
- Performance comparisons between the languages had been researched and dismissed already, don’t bother including them.
- It is perfectly valid to support your preference in terms of your personal goals (money, prestige, taste, etc.).
- Regardless of whether you can support your preference, please indicate it in your response. Morale impact is a key consideration.
Facts, Factors and Opinion
After compiling my own research, business case analysis, and the collective wisdom and opinion of my team, the following key themes emerged.
- Functionality (TIE): Functional differences between the capabilities of these languages were primarily cosmetic/syntactic/irrelevant(Appleman/Atwood), MSDN. There were a few IDE features that one language or the other had the edge on, but MS was already promising IDE parity in future releases.
- Learning Curve (VB.NET): Because our previous standard was VBScript for ASP pages, and VB6 for the middle tier object layers, VB.NET seemed like the quickest path to productivity. I was particularly concerned about the impact of forcing the developers to make the jump to a completely different language at the same time they would be also required to get up to speed on the .NET framework and ASP.NET.
- Existing Code (VB.NET): We were maintaining a significant amount of existing VB6 and VBScript code that would need to be ported to .net. Visual Studio provided tools to automate most of the conversion from to VB.NET, but considerable extra time would have been required to go to C#.
- Product Road maps for .NET languages (VB.NET): An MSDN magazine article comparing the road maps for the two languages indicated that VB.NET was going to continue to be optimized for rapid application development while C# would follow the tradition of C++ and trend towards power-user features. The direction of VB.NET was more relevant to our development efforts which were mostly on CRUD type applications.
- Developer Preferences (VB.NET): Despite the tendency of most to gravitate towards the familiar in platform wars, C# had a good showing. The balance was tipped by a few developers who had already started down the VB.NET track of their MCSD certifications. I hate to reinforce the stereotype, but it was interesting to note that the more senior developers were mostly in the C# camp.
- Developer “Street Creds” (C#): Almost all of the developers subscribed at least weakly to the popular notion that C# experience would command a higher premium than VB.NET by riding the coattails of C++ as a more respected language. Whether justified or not, it appears that this rumor has become fact.
- Product “Street Creds” (C#): There was also some concern that the “taint of VB” would hurt the perceived professionalism of our software among our customers. I have not yet seen evidence of this, however, we don’t advertise the language we use, and our customers don’t generally ask or care.
- Recruiting (TIE C#): There was a lot of discussion that MS was strongly favoring C# as the language of choice for .NET and that most developers were following suit. I was somewhat concerned about the possibility of VB.NET becoming marginalized and creating recruiting hurdles. That is, if VB.NET became uncool, it might be difficult to get people to respond to our job postings even if we didn’t discriminate against people with only experience in other .NET languages. On the other hand, I reasoned that we might be able to avoid paying a “C# premium” that didn’t guarantee any associated additional value add over a competent VB.NET programmer. I think that predictions of VB.NET’s demise were very premature as it continues to have a solid following. However, in retrospect, I think I underestimated the impact of the decision on recruiting. I suspect that some of our recruiting difficulty (even with very competitive salaries) can be attributed to the fact that VB.NET developers readily apply to C# jobs, but the reverse is not as common.
- Language Obsolescence (Non-factor): A small contingent was even predicting that Microsoft planned to phase out VB.NET in favor of C#. I just didn’t buy into this notion given my experience with how slowly Microsoft has retired product lines in the past. It took them 27 years, for example, to retire FoxPro after acquiring it, and salvaging it for parts to include in their competing database package, MS Access. So far it appears my skepticism was warranted.
Recommendations
As I have already mentioned, our team went with VB.NET. I still think it was probably the right decision given the skills of my existing team and our considerable investment in legacy code in VB based languages, despite the minor difficulties it has created for recruiting. Absent either of these preconditions, however, I definitely would suggest a preference for C# for any manager going through this decision today. That said, this article is no substitute for your own research. As is the case with any heated topic, there is an abundance of misinformation, some of which may even be repeated by members of your own team. One resource that I have come to trust over my years in this industry is Dan Appleman, who has published a highly regarded e-book, Visual Basic .NET or C#, Which to Choose? (VS2005 edition).
The lesson that can be drawn from my experience, however, is not so much about a preference of one language over the other, but instead the importance of involving the whole team in the change management process. This decision has major ramifications on their professional careers that extend beyond the walls of your organization and has the potential to create significant anxiety among them. Manage that anxiety by including them in the process, making it clear that their individual interests are being carefully considered, and the making the decision objectively and transparently as possible.
Links to the Fray
- Top 10 reasons C# is better than VB.NET
- Top 10 Reasons VB.NET is better than C#
- Wikipedia’s comparison of VB.NET and C#
- VB.NET vs. C#, Choose your weapon
- VB.NET vs. C#, Pounding on Performance
- VB.NET vs C#, Security Concerns
- The Three Million Dollar Question, VB.NET or C#
- C# and VB.NET Comparison Cheat Sheet
- CodeProject’s Complete Comparison of VB.NET and C#
- Selecting your primary programming language
Filed under: Managing Software Development | Tagged: .net, c#, management, platform wars, programming, programming languages, software development, technical, vb.net |
Improving Software 
I am interested in any opinions from programmers about whether you take pause when considering a VB.NET job. That is, for you personally, would it deter you from applying to or accepting an offer for a job that primarily used VB.NET. If so, what language do you use most often in your current job?
I wouldn’t consider a VB.NET job. In my experience, VB.NET guys barely grasp patterns and object-oriented programming. It’s not fair to lump all VB.NET guys in the same boat because I know a lot of really smart VB.NET guys… but a *lot* of VB.NET guys just don’t get it.
There’s more to programming than just the code… and certainly more than just the language. While you can’t really judge a book by its cover, you often can tell a lot about a programmer by his / her choice of language.
I went from 6 years c# to a fulltime vb.net job. The ability to graceful code in jquery,json,ajax,html depends somewhat alot, if not fully on camel casing syntax. Vb.net does not require syntax, which is my greatest qualm when our vb.net developers stumble on syntax coding errors in javascript. Out of sight out of mind, until you see a red exclamation mark in the UI.
I am a Java developer, and by hobby a C and assembler developer. Personally, I would _not_ take a VB.NET position. I would even hesitate from taking a C# position, however would be open to it. If I leave Java, I will probably look for something low level for embedded devices.
Thanks for your feedback. Aside from being a Java person and assuming you were going to .NET, what would be the rationale for not wanting to take a VB.NET position? Could any other aspect of the job compensate enough to convince you?
You forgot something incredibly important in the dinstinction between VB.NET and C#…..and perhaps your decision was made without consideration to this due to the version not having it…..but what about the MY NAMESPACE in VB.Net?
It’s classic, refined, and substantially makes it easier to do things in code without having to jumpt around a zillion namespaces in the .Net framework.
I find the MY namespace invaluable and something C# just doesn’t have.
You ultimately chose VB.Net and you have been rewarded for it with the added syntactical sugar of the MY namespace!
That is a good point, and you are correct that it wasn’t a factor at the time because this decision was during the era of the 1.0 version of the framework. Another reason I didn’t get into the syntax too much is the intent to cover this from the perspective of a manager. As evidenced by the links at the end of the article, the technical differences have already been covered, recovered, and covered again in numerous other articles.
Thanks for your feedback!
You did not consider any application API support (both Microsoft and 3rd party). That could be a major consideration for some IT shops.
I’m not aware of any application API’s that support either VB or C# that don’t equally support the other. Did you have a specific one in mind?
[…] C#.NET: A hybrid of C and Java that attempted to lure defectors from the Java camp to the .NET platform. It also provides an easy transition for C++ refugees who are sick of the annoyances of manual memory management and having 9 incompatible ways to implement a simple string. (via Software++) […]
[…] both trenches but instead describing the process he and his company went through to solve the C# versus .NET dilemma. He basically used the following criteria to qualify each language: Functionality, Learning Curve, […]
Great choice going with VB.NET Especially with the co-evolution of the languages, VB will be on par with C#. I work a very large metro hospital in L.A. All our new Win development is on VB.NET We chose it over C# because maint., time and with version 2010, we see VB.NET as not having problem keeping up with C# now.
came across this article as our dev team is considering a switch from VB.Net to C#. In your opinion: what, if anything, has changed 1.5 years after this was written?
Even after another 1.5 years the opinions/observations made in this article still ring true to me. I’d still favor C# for new projects/teams.
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.
Hmmm, I used to program in C++ and VB 6. Now I program in C# and VB.NET. The difference between C++ and VB6 is massive as the languages target entirely different type of applications and the languages differ immensly.
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?
It’s hard to take a developer seriously when the language they use has the word “Basic” in it.
Yes, that language is unfortunately named. I really wish they had changed it when they introduced .NET (or even VB6) because other than some syntactical similarities with its namesake it really is an entirely new and full featured development language. On the other hand, it can be a handy tool to identify language snobs who judge a language solely based on the name.
John, clearly a good and valuable post since it’s still being talked about two years later… and I see you’re still replying to comments.
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?
Actually, I made that call back in 2003, I just wrote the article in 2009 as a retrospective. At the time I felt that it would be beneficial for the team to focus on a single .NET language to maximize code re-use and focus on maximizing their proficiency in whichever language I picked. Also, I was big on the notion of self-directed teams, which is a core belief in the Agile movement. I weighed heavily that my team (at the time) preferred VB.NET. I still contend that the languages are functionally equivalent in all important technical respects.
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.
The vb.net vs C# debate is meaningless today. Yes, the community prefers C# but both languages provide the same functionality. There is no project that can be developed in C# that could not be developed in vb.net or vice versa. Today it comes down to syntax preference and what development teams feel more comfortable with. we are strictly a C++/C# shop but we could as well use vb.net for what we would develop in C# and the functionality of the app would be the same. In 2012 both languages are just as powerful.
So, here we are years after you made your decision, and still talking about it. I have used both languages off and on since .NET was first released. I prefer C# lately because I find it distracting to go from the curly bracket world of JQuery and JavaScript back to the “If Then…End If” world of VB.NET . I was so glad when Microsoft include “Using” in VB.NET and I agree that they may have reached a sort of parity with VS2010. Now, on to VS2012, HTML5 and all those new JavaScript libraries that seem to pop up every day. BTW, I really like Razor and MVC (uh oh, more curly brackets).
Very nice post and this question is one of the most popular when it comes to software development.
for some reason c# was and is more popular than VB.NET even when it comes to development community help … i think this is because of the c or c++ background for most of our current senior developers. for example if you are looking for a solution in a code problem if you gonna find a solution with the community forums its probably will be in C#
therefore every visual studio developer should know both.
Regards.