I have one afternoon to extol the benefits of .NET over VB6... what do I say?

Question

My company is a small twenty-man engineering firm. All the application programming here is done in VB6 by two people, who have taught themselves VB6 from an assembly background while working here for the past 25+ years, and myself.

As a result, the VB6 code is riddled with horrendous code smells, like tons of stringly typed variables, terribly long functions, hundreds of public global variables (some of which are preferred over passing around arguments and returning values,) and not a single object class. Refactoring is nigh impossible, and any changes require too much digging through code, and once made, always seem to introduce more holes.

My boss is realizing that VB6 is a dead technology, and is willing to listen to my pleas of moving to .NET for new development. We are moving forward to .NET, but he sees it as a way to keep up compatability with the newer Windows OS's, not as a way to write better code.

How can I best explain the benefits of .NET language over VB6, beyond mere up-to-date-ness? What can I say to best emphasize that the move to .NET is a good move but also that it means our current programming paradigm should also begin to change? As soon as my boss hears that Visual Basic .NET looks just like VB6, I know that his first instinct will be to simply convert our old code mess to .NET.

I understand that it will be impossible to change anyone's mindset in a single afternoon, but how can I at least convince my assembly-toting boss that things like strongly-typed variables, custom classes, and private fields aren't a total waste of time and energy?

Answer 1

Short Answer: There is nothing you can do to change their minds based on the criteria you listed in the question which are all technical. This is the equivalent of a religious debate. The quickest route to failure is to present an argument that is not from the point of view of the audience, in this case business owners.

Longer Answer: Change in business is driven by one thing and one thing only. Profit to the bottom line.

... how can I at least convince my assembly-toting boss that things like strongly-typed variables, custom classes, and private fields aren't a total waste of time and energy?

They can not only be a waste of time and energy but more importantly they cost you money! You must be able to quantitatively show that your suggestions will lead to a substantial profit over time. Just claiming clean code is "better" isn't enough, because clean code costs way more to produce.

If you can articulate how the cost of using modern technology will lead to ($COST + X) * TIME = $PROFIT, where X is a non-trivial postive number and TIME is relatively short you can create a compelling scenario.

Another way to calculate the ROI ( Return On Investment )

If this ROI/ROR is a trivial number, especially over a long period of time, you don't have much of a business case either.

How does your company actually make their money?

how many lines of code? how many customers? how much revenue a year does this software produce? is revenue mostly support contracts? or new licenses? is the target market stable? expanding? contracting? is the software a loss leader to some other much more profitable product?

It is hard for a good business man to ignore money laying on the table.

Of course you have to be able to back up your statements with hard facts. This means you need to be able to provide real numbers that show you really understand the actual business and not just academic technical details.

Not just the Pros

Also providing a detailed risk analysis and what these risks would $COST if they happened, would go along way in convincing them that you have a realistic case and aren't just whining that you don't want to be doing VB6 anymore.

Teaching old dogs new tricks

... What can I say to best emphasize that the move to .NET is a good move if and only if our current programming paradigm also begins to change? ...

Changing or Not Changing the programming paradigm to be as idiomatic as possible of the new technology is part of the risk analysis. But this is a separate argument only after you have proven there is significant money to be made by making a change in the first place.

Business people tend to listen to business cases just like technical people tend to listen to technical cases. All your cases in your question are espousing technical merits which are academic at best in your situation.

Prediction

I am making a few assumptions here VB6 app, small shop, few developers, 2 older developer/business owners is pointing to a niche market app that is probably mature ( bugs and work arounds are known ), fairly feature complete and relatively stable, regardless of the "mess" the code base is. This leads me to believe that the small user base isn't growing dramatically year over year either, which leads me to the following conclusion.

That there really isn't going to be any real compelling business reason to change technical direction with this application. And up porting to VB.Net is a waste of time as well because you will just have the mess but now with more of it, and 2/3 of the development team not dedicated to learning anything new. Good luck.

Answer 2

I have a customer whose flagship product is written in VB6 and maintained by 3 people. I came to help them because they had a partner that wanted them to call a web service. That's very hard to do from VB6, but easy from VB.NET or C#, and I wrote them a .NET assembly that looked to VB6 like a COM component so they could call it. Then they needed to offer a web service to someone. Then they wanted to write a little standalone utility and it was going to need to encrypt and decrypt some information, and to parse some XML. I taught them to write that in .NET. Over the last 5 years or so, more and more of their code is in .NET even though the flagship product hasn't shrunk at all. There are parts of it they hate - every app has them - and where they can they are pulling these parts out (now the shrinking starts) and putting them into services or separate utilities. The rest of it will be converted holus-bolus to .NET. Yup, bad variable names and all - to my mind there are plenty of benefits to moving to .NET even if they don't change their current programming paradigm. These include:

• you can use the latest Visual Studio with better searching, better Intellisense, faster builds, etc
• you can integrate with a decent source control system (ie not VSS)
• there are libraries that come with .NET for free that make short work of things like encryption, XML parsing, image processing, and more
• internationalization and localization is much easier on a .NET project (this, with an inquiry from a huge Canadian customer who would need both French and English versions, may have tipped the balance for my client)
• inexpensive control libraries (Telerik, Infragistics, ComponentOne etc) give you amazing capabilities for almost no cost
• it will be much easier to find temporary help, like a summer student, in circumstances where the time spent to teach them VB6 is not worth it (don't discuss how you feel about teaching it to a new fulltime hire)
• your application will be UAC aware, so it will run better on Vista, 7, and 8. It won't need to be run in XP compatibility mode

There's more, but surely that's enough?

The matter of programming paradigms, strong typing, the compiler is your friend, encapsulation is your friend and so on is to my mind (and I get paid to have these opinions) entirely separate. If you want to die on that hill go ahead, but you'll be dying with a copy of VB6 open.

Answer 3

I started with a VB6 project a few years ago (company's custom ERP system) and I've slowly been migrating it to .NET. It's somewhere around half-done.

First of all, converting from VB6 to VB.Net is almost always a bad idea (and I did a lot of research on that). There's just too much different. Also, if your boss thinks that VB.Net is "just like VB6" then he's completely mistaken and you have to change his outlook fast.

My strategy was to keep the two code-bases separate and maintain them separately and then slowly move entire modules from VB6 to .NET but only when there was a significant change about to happen to that module, so we could amortize some of the cost. Even so, rewriting is a big expensive and risky task.

There are two ways to integrate existing VB6 with new .NET code (and you'll probably be doing that for a very long time, so you'd better get used to the idea). The first way I went about it was to start writing small modules in .NET and then have the main VB6 application launch the .NET executable passing in some command line parameters. This worked, but be warned that .NET has a start-up time hit of 4 to 10 seconds, so you're limited in what you can do this way.

Once it started to get really painful, I flipped the strategy and used the method from this CodeProject article to display the existing VB6 forms in my main .NET application. Once I went down this route, I was able to incur only one .NET startup time hit, and use ClickOnce for deployment, which was a godsend compared to how the VB6 app was deployed previously.

That said, here are the advantages I find in .NET over VB6:

• Better persistence frameworks (NHibernate, EntityFramework, Linq2Sql etc.)
• LINQ (I can't stress enough how important this is)
• Generics!
• Lambda syntax (solves a whole class of problems like "hole in the middle" elegantly)
• Similarly Action and Func types
• Reflection (something that you rarely use, but when you do it's huge)
• Much better unit testing support (of course, I doubt you'll convince your other employees to unit test, but you should)
• ReSharper (and other refactoring/profiling tools) (10x better than MZ-Tools)
• ClickOnce and/or Setup/Installer Projects
• Windows Service Projects
• True object-oriented support (VB6 is based on COM and is really bad in this dept.)
• Static typing
• Baked in XML support
• WPF and Windows Forms (VB6's controls are very limiting)
• WCF
• Much more example code online
• Exceptions (VB6's error handling is absolutely terrible by comparison)
• Visual Studio's source control integration
• Decimal type (VB6 never had a first class decimal type, even though it has CDec)
• First class support for Guid
• First class support for 64-bit integers
• Better collection libraries
• ReportViewer
• Multithreading, task parallel library

Disadvantages of VB6:

• You will notice a performance it. It might not be enough to worry about, but trust me, you'll notice it. VB6 compiles to native code after all.

To be fair, here are some disadvantages of maintaining a combined VB6/.NET solution:

• Maintaining two data access layers (assuming your VB6 app actually has one)
• Extra wiring to expose services/forms/etc. from one side to the other
• Twice as much complexity/architecture to keep in your head

Now, as you've hinted at, you really ought to rebuild your architecture from the ground up if you start writing code in .NET. However, it sounds like none of the people at your company are familiar with either the .NET and/or Java programming world, which is where a lot of the patterns and practices that are common to big enterprise frameworks come from.

If you take someone who's used to dragging a button on a form, double clicking on it, and writing some SQL strings directly in the click event handler, and that's been working for them, it's really hard to make them see an advantage to following SOLID design principles. On the other hand, if you bite the bullet and decide that all new code is going to be covered 90% or greater by automated unit tests, then you'll quickly realize that's really hard to do unless you adopt the SOLID design principles.

So you need to take a really hard look at the reality of the situation. In my case, I was the only programmer, and I was determined to have all new code be unit tested, even though I had no experience with it. I can't stress enough how much this negatively impacted what I could get done in the first week, even first months. Still, I was determined to do it, and I had buy-in from management. Most people don't have that luxury. Now I have lots of code and I just finished a major refactoring with almost no issues.

Realistically, you're not going to be doing unit tests, which means it's harder to justify principles like dependency injection to your team-mates. You're going to have to sell .NET on the merits other than architectural benefits. You have to focus on better library support and better tools. That's the only thing that will resonate. I would suggest the following in your demo:

• Create a Windows Forms project (stay away from WPF and xaml - it's too startling)
• Connect to a SQL database (some test database)
• Use Linq2Sql or EntityFramework to generate a data model for it
• Create a repository class that has a method to return some list of entities
• Write a query in that method using linq, point out the intellisense
• Point out that linq works on all objects, not just entities
• Show that if you change the database and regenerate the model, you get a compile error
• Drop a DataGridView on the main window
• Demonstrate databinding by populating the grid with the entities from the repository
• Point out all the cool stuff about the grid that's so much better than VB6
• Create an .rdlc file (report)
• Make a simple report inside Visual Studio
• Drop a report viewer on the window and render the report inside the report viewer
• (Obviously you need ReportViewer installed and have practiced all this first)
• Come up with a "hole in the middle" problem and then demonstrate solving it by creating a method that takes an Action as a parameter. Do this first by passing another method as the parameter, and then blow their mind by passing an anonymous delegate using lambda syntax
• Demonstrate generics by using the List<T> and Dictionary<T1,T2> collection classes and show how it creates strongly typed code (VB6 has similar stuff, but it's dynamically typed)
• Write a foreach loop that's embarrassingly parallel, use System.Diagnostics.Stopwatch to measure the time it takes to execute, then use the task parallel library to change the loop into a Parallel.Foreach loop and demonstrate the speed-up, assuming you're on a multi-core machine.
• Demonstrate the ability to add a global exception handler (this is something that VB6 can't do)

That's what I would do.

Answer 4

It seems to me that this is a situation where you will need to put on your politician hat instead of your programming one. You must be very mindful how you make your argument and that you do not antagonize your audience. Make sure that you show the advantages of .Net instead of showing the disadvantages of VB. Arguing the disadvantages of VB will put your coworkers in a position where they need to defend their decisions and force them to admit that a language they have a heavy investment in is a bad language. Instead, show them how moving to .NET will augment the tools they have available to them and make their life easier.

My ideal way of making this argument would be find a task or piece of code that everybody is constantly complaining about and fix it using .NET. I'm not especially familiar with VB, but here is a short list of annoying tasks that would probably be made easier by using .NET instead of VB.

• String Manipulation
• XML Parsing
• Searching/Matching/Regex
• Math (newer languages usually have faster, more comprehensive math libraries)
• GUI building/design

Pick any one of the the above tasks, or some other task specific to the projects you usually work on, and sit down with them and actually write some code, from scratch, that handles the problem quickly and easily. Actually showing the process of writing the code will show off the tools that newer versions of VS bring to the table and provide evidence that moving to .NET will not make anybody's life harder.

Going into this, you absolutely, positively must do you're homework. If you show up unsure of how tools work, or have code that doesn't work correctly, you are never going to be able to win them over to your side.

Answer 5

The first thing you say is that VB6 is no longer supported by Microsoft. Whilst you can keep it running, you have to understand its options in the long-term are nil. I don't even know if VB6 apps will run on Windows8, or if the IDE itself will run on Win8.

So, you effectively have to do a rewrite eventually, and if that's the case, you might as well start now rather than later, giving you plenty of time to figure out which new tech you want to use (while VB.NET sounds ideal, this is your opportunity to try something more cutting-edge, like make the app work on iPads).

In the short term, you can mitigate the problem a little by introducing new sections as COM components for the existing app to consume, hopefully these components will remain when the inevitable rewrite happens.

I wouldn't bother with technical arguments over why .NET is better than VB6. You will be on to a losing argument there, technology in itself never solves problems. Its up to you how you apply that technology, and if the VB6 app is solving stuff for you, there's no argument to answer. You can talk about ease of maintenance, or availablility of experienced staff, but once you do that you admit that your existing staff have no expertise in the new tech and will have to be trained, and then take some time to fully get up to speed with it. You will also have to answer the questions about how a lot of rewrites end up worse than the original project (sometimes due to the lack of expertise, sometimes due to too-grand designs).

Answer 6

Give him the "old car new vs car" analogy:

Yes both will probably get you to your destination. However the new car doesn't need a crank, it doesn't need a choke, it doesn't need maps, its wheels do not lock when you brake sharply, and finally you are far more likely to walk away from a car crash.

• VB6 is legacy, its the new COBOL
• .NET has better frameworks
• .NET has better tooling
• .NET has better performance
• .NET has better IDE
• .NET has better language support
• .NET has better features
• .NET has better community support

Answer 7

First off I think you should change the question (not on stackexchange but within your company). It's not so much why is .Net better that VB6, but more like since VB6 is no longer supported it is time to move on, but to what. Ask the stakeholders what should that 'new' technology be? Maybe it's not .Net.

But it sounds like you need to move to a new technology AND get some good programming patterns and practices in place. The answer to the second part is much harder. You probably have to do it in small section of the application and prove it worth while, that is it is more stable, easier to maintain, etc.

Answer 8

Tell your bosses to write two want ads. One for C# developers. One for VB6 experts. Put 'em out there. Compare results.