Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
For the purposes of this question, the code base is an ASP.NET website that has multiple pages written in both C# and Visual Basic .NET. The primary language is C# and the Visual Basic .NET webpages where forked into the project as the same functionality is needed.
Should the time be taken to actually rewrite these pages, including going through the testing and debugging cycle again, or would the be considered acceptable as is?
There are three points you should keep in mind:
First off, like many have said if it’s not broken, then why go through the effort of changing the code base. You risk adding bugs during the language transition, even if they’re both .Net languages running in ASP.Net.
Second, I’m going to assume there was a valid reason for forking the project and using VB.Net instead of continuing with C#. What were the reasons behind this language change? Are those reasons no longer valid? Consider the validity of the assumptions that led to forking into a different language.
Third, are all team members competent in C#? Migrating all the code to C# might be a burden if several team members are not proficient in it.
Finally, I would suggest adopting coding standards and focus all new development in one language from this point onward. Along with those standards you might consider a policy dictating that if you need to modify/fix VB.Net pages that this page should be migrated to C#.
At that point the VB.Net page is no longer ‘not broken’ and you’ll most likely have to go through the debugging / testing stage anyway to verify the fixes/changes. So you’re adding the cost of the migration to whatever bug fix. In this manner you can slowly migrate the code to C# without incurring a large one time cost.
If you balk at the cost of having to migrate a page along with any bug fix or change in a VB.Net page, then take note of this. You most likely don’t have the time or resources to do a migration of ALL the VB.Net pages. As a mass migration would require even more time and would sensibly require you halt all work/fixes on the VB.Net pages while the migration is under way. This might be an indicator about whether migrating to C# is an option given your business needs.