Convert a team from VB.Net to C#.Net

Question

I am currently running a team of 5 VB.Net developers and have decided to make a switch to C#. The team builds and maintains around 20 different applications that run our whole platform, so the code-base is fairly moderately sized.

There are several factors for making the switch, but the biggest is to overcome recruitment issues. VB.Net developers are hard to come by in our region and over the course of this year we will be recruiting 3 or 4 more. I work with several recruitment agencies to find talent and the feedback is fairly overwhelming for this point. All of our developers already have C# experience, so I have no concerns there.

My question is not so much about the viability of switching to C#, as we are already certain on this, however what I need advice on is the approach. The way I see it there are several options:

1. We use the team to convert the entire code base at once and then work in C# moving forward.
2. We factor in time to convert smaller chunks of the code base during project development.
3. We outsource the conversion to another agency
4. We employ a new C# developer and get them started on the conversion whilst slowly migrating the team over

I'm sure there are companies who have had to make this switch in the past, so really hoping someone has advice from experience.

The question (for clarity): What is the best approach for migrating a team from VB.Net to C# with all of the considerations above?

Answer 1

If you currently have VB.NET devs who know C#, I don't think all 20 applications need any rewriting all at once. It's just too much coding, testing, rolling out and for what? Because your next few hires won't understand the code? Don't confuse C# coders who just hate VB with their not being able to understand it at all or with little training.

I would do the following:

1. New apps get coded in C#.
2. Current apps needing significant changes, get converted to C#.
3. New hires need to learn some VB even if it is a way to convert code or do minor trouble-shooting. They need to learn the systems anyway. They're not going to handle production code on day one. Have a plan to on board them. If they have contempt for VB, it's a great incentive to get it converted. If there are any new projects that are not too large, they could be involved in those. VB dev is just a part of their job for a limited amount of time. Don't let them feel stuck forever.
4. Determine apps that probably never need to be converted. This may change over time. Make sure this is enough for current team to handle. You may have some apps get phased-out.

A long-term plan where you address things as needed and convert in smaller chunks won't seem like such an over-whelming project. Bringing on 3 new devs is a major task. Don't convert code just for the sake of converting it. You may have apps no one will ever look at again.

Answer 2

Instead of trying to tell you what you should do, I'll share what we did.

1. Tests get written in C#, because, let's be honest, the VB codebase doesn't have any.
2. New classes are written in C# inside new class library projects added to the solution(s).
3. Small modifications to existing VB code are maintained in VB, but characterization tests are added before any modifications are made.
4. Ruthlessly refactor.
5. Once you've got significant test coverage, you can choose to migrate VB classes to your new libraries whenever it's convenient, a little at a time.
6. Retire as many apps / as much functionality as possible.
7. Don't touch any code unless you have an actual requirement from a user to do so. (There's a concept in Lean Manufacturing, don't do anything until a customer gives you a reason to do so. It'll treat you well here.)

Sooner or later, you'll have very little VB left in a project and good enough test coverage to "finish it off" and rewrite the thin GUI layer. Give it a nice facelift while you're at it. This approach worked extremely well for my team.

Will some of that VB code still be there in 2 decades? Yeah, but it doesn't matter if no one ever needs to change it. Be respectful of your employer's money. Rewrites rarely go well. If you're not concerned about the company's money, then consider your bonus....

Answer 3

The question (for clarity, as it seems some couldn't read the question in its entirety): What is the best approach for migrating a team from VB.Net to C# with all of the considerations above?

Migrating a team is a problem, migrating an existing codebase is another.

Regarding your codebase, @JeffO's answer is a really good one.

Regarding your team, since your current team is already comfortable with C#, I don't see much problems, but please note that C# may have some different conventions than VB.Net, and, while they share the same framework, developers that come with VB6 background usually have different standards than developers that come with C/C++/Java background.

For comparison purposes: C# Coding Conventions versus VB.Net Coding Conventions.

If you're expecting to hire more seasoned C# developers and you want to keep them in your team, it'd be nice to favor the adoption of the C# conventions among your current team while working with new codebase or refactoring old codebase. It's a matter of culture, which sometimes is hard to change in a well stabilished team.

Answer 4

C# and VB.Net are pretty similar languages, but you still want to reduce the risk as much as possible.

There are tools which can perform the translation semi-automatically.

You should do it one project at a time, since a project is the smallest unit you can translate. This reduces risk and will give you a good idea of how much time it will take, what problems you will encounter and so on.

You should not outsource the translation or hire a dedicated developer for the translation. Rather the developers which are already familiar with the code should perform the translation. Since they already know both languages, this will ensure a smooth transition and they will be familiar with the translated code.

Do not attempt a refactoring or restructuring of the code in the same pass. Translate 1:1 even if this means writing "VB in C#", relying on the Microsoft.VisualBasic assembly and so on. You want to ensure the translation succeeded without problems, before you start rewriting in a more idiomatic C# style.

Answer 5

Machado's answer already points to coding conventions and culture. I'd like to emphasize that a C# developer who does not want to work on VB code will not be satisfied with VB converted to "C#" which actually still is VB.

Make sure that your team understands - and lives - the concepts of object-orientation. Do they place the code where it belongs to? Do they separate concerns (e.g. UI and business logic)? Do they understand SOLID? Do they understand how to have objects interact (design patterns, dependency inversion)? Etc.

True there are many C# developers who don't know that either, and it will be important for you to find that out during the interviews. But those who know those concepts might want to leave you soon if nobody else observes them.

Well, you could read that the other way round: find the C# developers who don't know these concepts, and stay with what is said to be typical VB code (though it was "converted" to C#)...