Here’s an awesome question I was recently asked:
So far, our line-of-business apps are in Visual Basic. We are moving to Visual Studio 2013. On the internet, we find more samples in C# than Visual Basic. What language should we choose?
The overarching principle here is that an enterprise needs to have an established, common technical architecture and set of development standards – including language. Having said that, every enterprise should also have a roadmap for change adoption, adjusting to trends and upending long-held traditions for the sake of the enterprise and their developers.
First – parity
Microsoft is dedicated to language parity.
The Microsoft Language Team has worked hard to ensure parity between the two .Net languages – C# and Visual Basic. In fact, the 2014 compiler, codenamed Roslyn, compiles C# in a version written in C# and compiles Visual Basic in a version written in Visual Basic. Such an undertaking has helped ensure the parity, capability, and quality of both languages. For that reason, neither is technically superior.
Second – new blood
Schools that teach software development, teach C.
The reality of the industry is that CS students learn C++ in school. C# is a C derivative, so most students wanting to develop on the Microsoft platform are naturally attracted to C# - if for no other reason, because it is familiar. When samples are written for students, and when samples are written by students, they are in C#. As a result, in part, the majority of samples are in C#.
Third – availability
So many developers, so few Visual Basic developers.
The previous point has a secondary impact that as the developer community greys, the labor pool of younger, junior, cheaper, and more available developers is a C# workforce. It means that it is easier to find C# developers. It means it is cheaper to hire C# developers. It means that Visual Basic has no technical reason to be avoided as much as it has practical and economic considerations.
FoUrth – old school
One man’s proven tech is another man’s out-dated tech.
As students begin to graduate and fill enterprise developer and architect positions, they bring with them a perception of our industry. That perception is that modern developers code in C# and modern software is coded in C#. Their experience and their peers reinforce this perception. The reality is not important here, the perception is an absolute. And, it drives attitude.
Sixth – turnover
Every developer wants to keep up with change.
The perception that C# is the modern preference, true or not, is important to understand for the sake of employee turnover. Developers notoriously are short-lived in their jobs. Since the recession, this has slightly waned, but it will only get worse. If your company embraces industry trends, the latest frameworks, forthcoming architectures, and technical advances – your developer workforce will feel challenged, more likely satisfied, and more likely staying in their jobs. As a result, your company will experience less turnover – which saves you productivity, money, and headaches.
Seventh – third parties
Microsoft is dedicated to Visual Basic, third parties are not.
As the trend toward C# extends across the industry, third party tooling and resources cater to that trend and not to the exception. Again, although Visual Basic is the technical equal to C# and even through Visual Basic may have some genuine productivity benefits, those are eclipsed by the reality that tooling and online resources cater to C#. This includes templates, snippets, code examples, walk-throughs, extendable libraries, blog articles, and other valuable resources in the developer’s toolbox.
Eighth
The internet isn’t written in Visual Basic.
Not so many years ago, I could not imagine doing my job without http://Google.com. Today, I could not imagine doing my job without http://StackOverflow.com. Most of the .Net questions I encounter on StackOverflow are in C#. Most of the answers I find are in C#. So, when your developer needs to answer a question, are you giving him a productivity advantage by requiring him to translate the wealth of C# questions into Visual Basic? You really aren’t. You’re likely slowing him down.
Ninth
Future tech is typically introduced in C#.
Visual Basic is not ending. Visual Basic is a pervasive language. It is the basis of thousands of line-of-business applications serving enterprises for years. It is based on Basic, and as powerful and as flexible as C#. But when you attend conferences or when you read magazine articles, what languages are the presenters and authors showing? They are showing C#. Developers use these resources to sharpen their saws. Visual Basic developers can’t help but be discouraged. C# developers, on the other hand, sometimes don’t even notice that the world caters to them.
I am going to circle back here to the idea of job satisfaction and employee turnover. The more discouraged or dissatisfied your developer, the more likely they will seek employment elsewhere. Only by challenging your development team and stretching their skills with exacerbated technical adoption can you create a culture of encouraged growth. The minute your developer thinks your company is holding back his career he hops on http://Monster.com – and I think he should. He has a career to protect.
Tenth
Multi-platform options aren’t that flexible.
A peripheral add-on here is a call-out to Xamarin. They sell a code compiler that takes C# code and compiles it to native Android and iOS software. This lets developers create a single code base in C#, and leverage their logic on multiple platforms. Enterprises servicing mobile applications across the spectrum of platforms suffer from multiple code bases. Xamarin narrows the gap between the platforms. They can increase productivity and software quality. They are, incidentally, the only player in this space. And, they don’t speak Visual Basic.
An ode to beta software
Design for shelf-life
I also believe that it is reasonable, if not necessary, for enterprises to use beta software in emerging line-of-business projects. Unlike small one-off projects, enterprise line-of-business projects take one or more years to complete. Though the software architect chooses the next version of Visual Studio or the .Net framework while still in beta, by the end of the project they are is already outdated. Choosing the safer, easier, proven version of tools or frameworks just means the end-of-life for the software comes even sooner. Choosing new software extends your solution’s shelf-life. Choosing new technology also invigorates your development team to value your project for themselves, creating buy-in and inordinate commitment.
Finally
Technical decisions are not always based on technology.
A good director, manager, and architect ensures there is a common technical architecture and developmental standards for the sake of corporate vision and developer productivity. They ensure the vision is understood by each member of their team, for the sake of buy-in and peer accountability. They ensure the vision is followed, for the sake of project consistency and product maintainability. And, they ensure the vision is flexible, not driving toward a predetermined conclusion without the ability to adopt to change.
Conclusion
Right or wrong. It is what it is.
Can you use Visual Basic in your enterprise apps? Absolutely. Visual Basic may even be superior in its readability and productivity to C#. Should you use Visual Basic in your enterprise apps? Consider the life of your product, the developers on your team, the developers you want to hire, and the direction of the industry. The answer may seem clear, but in some cases it is not. Your existing code base may be so large that hiring and training a developer into the tech you need is worth it. You may also compensate developers so aggressively that they can handle non-industry trends. But, the easy path is C#. Right or wrong. It is what it is.
Not too hasty
Hey! This is not a recommendation to rewrite your existing applications. Of course, not. This is not a recommendation to fire your Visual Basic developers. Of course, not. This is a recommendation to look around, measure the trends insofar as their impact to your business. Survey your development team. And, consider again, the current direction of your architecture, patterns, and standards. Are you resting on decisions made in an irrelevant context? Are you resting on decisions made in an outdated environment? It’s up to you. Not me.
Disclaimer
Sorry, but I have to add this. There is absolutely no way I am speaking for Microsoft here. Microsoft loves Visual Basic developers and C# developers the same; like parents equitably love their children. Microsoft official samples are aggressively produced as multi-language. Their language support is not in jeopardy at all – this includes desktop support, Windows 8 support, and Windows Phone support.
In the end, this is not just a technical decision.
Though I may work for Microsoft, I am not speaking for them here. I am not trying to “sell” you or “tell” you the answer to this turbulent question. I am trying to talk through some logical observations – distinct considerations that together may help you draw the conclusion right for you. Not me.
Best of luck!
PS: Perhaps you have another observation?