# I have one afternoon to extol the benefits of .NET over VB6… what do I say? [closed]

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?

## closed as not constructive by user7519, Walter, user8, gnat, ChrisF♦May 17 '12 at 16:52

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

• VB6 developers are a dying breed? Try recruiting .NET developers and VB6 developers. See how many CVs you get for each. The fact that once the 2 old timers retire, there will be no replacement (or rather, very expensive replacement) should be enough of an argument. – Oded May 16 '12 at 19:56
• I appreciate that he may try to, but most self respecting developers would stay off a dead language. Not sure when MS are going to stop supporting VB6, but it is getting increasingly difficult to find resources (and product end of life is another argument against VB6). Not sure how much this will help, but do study: msdn.microsoft.com/en-us/vstudio/ms788708.aspx - 2008 was the end of life of the IDE. And I like the "Custom Support Agreements may be available from Microsoft" - at what fee, I wonder... – Oded May 16 '12 at 20:01
• @Oded Unfortunately, none of these arguments really touch on the fact that VB.NET is usable as a stand-in for VB6, global public variables and all. Once we're using .NET, how do we actually use all of it's benefits? – dlras2 May 16 '12 at 20:09
• Maybe explain by examples. Is there some problem that is difficult to solve in VB6 that would be much easier to solve in VB .NET? Could you pick some examples from your code base and show how they can be cleaned up into better code in .NET that would not be possible with the features in VB6? – FrustratedWithFormsDesigner May 16 '12 at 20:32
• @DanRasmussen VB.NET could not import VB6 projects correctly (fixed yet?). It is non-trivial to upgrade. – user1249 May 16 '12 at 21:10

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. • unfortunately the cost of rewriting (plus training, plus gaining expertise) usually outweighs the cost of keeping the app running, at least in the short and medium terms. In the long term however, you run the risk that your rewrite itself may need to be rewritten in$next_new_technology. – gbjbaanb May 16 '12 at 22:19
• +1 religious debate. If OP wants to work in .NET he should get a job in a .NET shop; I'd say moving from VB6 to .NET in this company is a major risk with questionable benefit. – Kirk Broadhurst May 17 '12 at 0:48
• Great answer, except you skimmed over his part about "Refactoring is nigh impossible, and any changes require too much digging through code, and once made, always seem to introduce more holes." It's the last statement that's of value to the business. Demonstrating that they are unable to change the codebase without significantly costing the business money is a very valid argument in line with your answer. Of course, the metrics have to be there to back up that statement. – user53019 May 17 '12 at 16:57
• @GlenH7 personally I think what you quote is dramatic personal opinion and rhetoric because the OP doesn't show any concern for anything other than pushing their personal opinion and agenda. My answer is to propose that they aren't considering what the real driver for change would be and it isn't what they think or have considered. My point is incremental changes over a long term that are "expensive" will always be cheaper than what they are proposing over the same amount of time. Making what they said, and what you quote an untenable business argument. – user7519 May 17 '12 at 17:08
• Agreed that there was a degree of rhetoric in the statement. Some shops (and no, they're generally not the small ones) track failures / escapes so it's possible to generate hard metrics about the bugs. OTOH, most shops don't keep that information and it's nothing more than a "gut feel" which doesn't count for much in a business presentation. – user53019 May 17 '12 at 17:16

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.

• What do you mean by your closing paragraph? – dlras2 May 16 '12 at 21:03
• That "moving to .NET" and "let's all program a different way" are different, and that if you choose to fight the second one, not only are you unlikely to succeed, you're almost certainly not going to move them to .NET with that approach. I mean I agree they should program a different way. But the best path to .NET is "like what you have now, but with chocolate sauce and sprinkles!" – Kate Gregory May 16 '12 at 21:05
• I understand the benefit to approaching them as different problems, but the problem is that approaching them as separate problems simply ensures equally unmaintainable programs, just in .NET. – dlras2 May 16 '12 at 21:10
• You will have better applications (nicer controls, more functionality) and some better process (sneak in a source control and maybe even work item tracking) along with developers who now see that it can be done differently, and that the pain of changing is worth it because of these great benefits. They will be way more receptive to the next thing you ask of them. And "unmaintainable" is not binary. The code won't be great, but the situation will still be better than it was. You'll have proven credibility, too. – Kate Gregory May 16 '12 at 21:14

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

• 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

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.

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.

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).

• MS will be supporting VB6 on Intel/AMD PCs running Windows 8. You can't write Metro apps in VB6, but you can't write Metro apps in .NET either. Both are built on Win32. At least code written in C# for .NET is supposed to be easier to port to WinRT to run on Metro, but don't count on it being a simple rebuild. – Scott Whitlock May 17 '12 at 1:30

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
• Car analogies usually fail, and yours is no different. A thing that an old car has that a new car doesn't is that is paid for! If you owned a taxi and it was paid for and it was making you more money than it cost to maintain, and a new car would cost you more money to pay for than it made which would you rather have as a business person? – user7519 May 17 '12 at 0:04
• @JarrodRoberson It's paid for, but they tend to brake down more often, and after a while will no longer work. Car analogies are great. :) – Steven Jeuris May 17 '12 at 0:24
• Actually, this car analogy is good. OP's boss has that taxi going on and the OP should consider that while approaching him. A full switch cannot happen over a day, but let's start moving bits, changing pieces, one after the other. – ZJR May 17 '12 at 0:24
• The business owner designed and built his this himself. It has most likely paid for itself many times over, and the maintenance is for all intents and purposes free since there are are only 3 developers and he is one of them. Like I said, car analogies are terrible, this one particularly so and you make my point for me with your arguments which are completely off base business wise. New software will at best make him a much smaller profit year over year at best and lose him money for an indeterminate period of time at the worst. – user7519 May 17 '12 at 1:11
• Applications have no wear and tear entropy like physical items do, they don't naturally atrophy either, so they don't wear out, nor do they break down regardless of use so analogies with physical items, especially cars doesn't apply. An application will run forever as long as it serves it purpose. One company I worked for a few years ago had an old MS-DOS based machine that controlled the card readers on the doors. The idea that software wears out is silly. That said a good end of life plan should always be in place. Even if that plan is to never re-write the software. – user7519 May 17 '12 at 6:33

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.

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