When to Rewrite Your Software

That's pretty anecdotal and light on details... All they say is they rewrote their software and it was the right thing to do. OK, but I haven't really learned anything.

The VB version was a working prototype. They had built a war chest on its back but the prototype was blocking their future. It was making them vulnerable to the competition. They smelled blood in the water and it was theirs. The feeding frenzy was about to begin.

Taking the lessons of the past and a clearer understanding of the needs of the market place, they created a path to the future. Not a bad choice in my opinion.

I am not so sure about using C#. That is much too tied to a specific vendor and programming model. I am sure VB is best used as a prototyping and proof of concept tool. If you have need of a disposable program, its great. If it must live long, wide, and numerous, it has trouble being even as good as a poor choice. With the right choice and a good bit of luck, they not only survived but went on to thrive.

Looks good to me.

This article is better than I thought it would be. It's written by Neil Davidson, co-CEO of Red Gate software. I used their C# profiling tool a few years back, so my ears perked up a bit when I saw the author's affiliation.

The takeaway seems to be that if you've written your product on a platform (in their case VB6) that you can't take forward for whatever reason, then it might make sense to rewrite it.

Davidson freely admits that they rewrote their code for the wrong reasons -- they just couldn't think of anything else to do at the time -- but that it turned out well in the end for them.

Ironically, they were right about competitors nipping at their heels. I now use the profiler built into Vistal Studio .NET 2008 instead of the Red Gate profiler.