At Boomcycle, a Los Angeles based software development consultancy, we have seen first hand that when an IT colossus like Microsoft decides to change one of their development technologies, the ramifications are wide-ranging and far-reaching. For some companies, this change can introduce a near-term evolve-or-die crisis. For the luckier ones, there is still the unpleasant prospect of slow but inevitable obsolescence. In either case, there’s usually much gnashing of teeth and a lingering sense of betrayal, but the change must eventually be made or dire consequences follow.
What’s Wrong with Our Current Visual Basic 6 System?
In the teeth-gnashing phase, it is natural to question why one’s favorite IT-industry titan chose to fix something that didn’t seem broken. We beseech the sky and demand to know why .NET must replace VB6 because our entire enterprise is happy entering data and our business is humming along just fine. As it turns out, there are a variety of very good reasons:
- Moore’s Law: hardware has not only multiplied its fundamental measurements like clock speed and storage capacity, but multi-core, multiprocessor, and cloud systems have introduced qualitative changes in the way that hardware operates and these, in turn, place new demands on compilers and coding languages.
- Code bloat / Code rot / Code complexity: Just like you, your favorite IT giant has to maintain a lot of source code. If you think maintaining your code base is difficult, imagine trying to simultaneously manage the code base for the last five versions of Windows, MS Office, and all the development tools that Microsoft manages. At some point a redesign is necessary to address fundamental structural shortcomings.
- Competition and Innovation: The world of software development has many different code ecosystems constituted of different languages, different database engines, different libraries, and different philosophies. Most of these ecosystems are characterized by ever-increasing levels of code abstraction that make developers more productive, improve security, and take advantage of modern hardware capabilities and coding philosophies.
This is the march of progress and an IT giant must participate or lose ground to more expressive, secure, and elegant technologies.
Experienced engineers of all fields know that by the time you finish a large project, you’ve already thought of a dozen ways it could have been done better and differently. This is the advantage of hindsight and, rather than lamenting it as poor planning, we must realize that it is the very process of building a solution that forces us to test our perception of a challenge against the reality of that challenge. In practice, no two projects are truly identical and the devil is waiting in the details.
VB6 to .NET Conversion Advantages
If you realize that you are still looking skyward for answers, you might want to consider getting started on your VB6 migration sooner rather than later for these reasons:
- The .NET framework was introduced over ten years ago. The pool of VB6 developers has subsequently been shrinking for some time. The longer you wait to migrate your system, the more you will pay for coders with “legacy” knowledge.
- It’s getting more and more difficult to find a version of Visual Studio that can work with VB6 these days. You might have to check Ebay.
- Microsoft has so far continued to support VB6 runtimes, but this will not last forever. Aside from security and bug fixes, it is entirely possible that your code simply won’t run at all. Third party libraries and controls (e.g., Sheridan controls) have long since been abandoned.
At some point, your company will face a “convert to .NET or face the consequences” crises. As with most foreseeable events, it’s wise to prepare for the inevitable.