The Price of Everything

SmartRate was first cobbled together in Microsoft Access and Excel.  When I demonstrated SmartRate was good enough to move forward, I developed in a slightly archaic language - Visual Basic 6. 

By almost any measure, .NET is a superior language to VB6.  Development is faster, cleaner, and the third party tools for .NET are far better.

VB6 has one feature to recommend it.  Its bad reputation among architecture astronauts repels the people we really don’t want.  Many geeks care more about gaining experience in the latest hot technology than shipping good product.  Code that works and can be modified without a PhD is just too boring for some people. 

If AJAX is the Escalade of programming, VB6 is definitely a Buick.  Sure, there are some uncomfortable moments when a bank CTO asks about our development environment.  But ultimately, they are only trying to get a measure of our software’s quality - which I’m proud of.

The curative powers of VB were confirmed two years ago with our first programming hire.  I brought Ivan on to work in VB6/Access.  An incredibly sharp guy, ranked in the top 0.1% of freelance developers.  Hard-working, patient with people, and focused on getting the job done.  He’s got to be one of the most pragmatic developers I’ve met. 

Ivan worked past my show-me attitude and quickly convinced me Access had to go.  The database works fine for smaller projects, but gets stuck in the weeds when working on complex queries and millions of records.  We moved to SQL Server and immediately saw huge performance gains.

Although Ivan was happy to develop in VB6 and recognized the various drawbacks in converting, he eventually pushed the case for .NET.  He didn’t have as much luck.

Yes, it is better.  Yes, it lets us test our code more carefully.  And yes, Microsoft is phasing out support for VB6. 

But are the gains in development language at the expense of finding the right developers?  Plus, the conversion from VB6 is notoriously difficult.

A few weeks ago, Ivan forced my hand.  He singlehandedly converted the code in his non-existent spare time, secretly working 18 hour days and performing double work to make fixes in both the VB6 and .NET versions of the code.

I was a little surprised, but it’s hard to look a gift horse in the mouth.  For one thing, this conversion immediately solved our memory fragmentation headaches in working with 100MB bank data feeds.

We still had plenty of ground to cover.  How do we: 

• prove that nothing broke in the conversion? 
• install this version on customers’ machines? 
• catch unexpected errors? 
• time the upgrade so we don’t interfere with the release schedule?

We had a lot of back-and-forth to find good solutions to these issues, but Ivan had answers for everything.

The biggest question was answered by Ivan’s covert coding: is the move needed to make Profitdesk developers happy? 

A definite yes.  And that outweighed my fears about future employees.

Plus, I no longer need to mumble around bank CTOs.

Lesson learned: In real life, decisions need to get made - even wrong ones.  But in software, sometimes it’s better to just note the problem and keep gathering information.  Eventually, some problems work themselves out.

Bookmark to: