Recently a software developer came to me with a fascinating argument. He claimed that VB .NET is a poor choice for software development because it was more RAD than C# (RAD = Rapid Application Development for those who have forgotten), and that RAD tools lead invariably to bad code that is unsupportable and more costly in the long run. He based this argument on extrapolation from VB6 days, where VB6 was (of course) very RAD, and this resulted in copious amounts of bad VB6 code.

Now, there’s no denying that lots of very bad VB6 code was written. But does RAD really result in bad code? Are RAD tools really best for quick prototyping and “throw away” code?

This question is especially important as we approach Whidbey, where much of the differentiation between C# and VB .NET are in the area of RAD features, with VB .NET gaining edit and continue and native support for the My classes, and C# gaining refactoring.

To answer the question, let’s agree first that increased productivity is a good thing (in fact, in an age of increased offshoring, it’s arguably critical). But how do you measure productivity? Is it in lines of code per dollar spent? That’s a fair definition – but only if you qualify it. The lines of code has to have a specified quality level, and dollars spent has to include the lifetime cost of the software, not just the initial coding and testing.

RAD tools clearly allow you to write more code faster. But is it necessarily bad code?

I think not.

The reason that so much bad VB6 code was written was not because VB6 was RAD, but because it was easy. In fact, VB6 made writing software so easy that anyone could be a programmer, and so everyone was. Doctors, Lawyers, Bankers, Hobbyists, Kids – everyone was writing VB6 code with little or no training.

Now, I don’t know about you, but I still have copies of a few of the programs I wrote when I was just starting out, before I’d actually gone to school to learn a thing or two about software development. There was some BASIC, some Pascal, and looking at it now, it’s all pretty ugly.

So let’s get real. Bad programmers write bad code. Good programmers write good code. RAD lets bad programmers write bad code faster. RAD does NOT cause good programmers to suddenly start writing bad code.

RAD tools can make a good programmer more productive, because they speed up the coding process without compromising the level of quality that a good programmer is going to achieve.

I haven’t yet completed my comparison of C# and VB .NET for Whidbey (I’m in the early stages of updating my eBook “VB .NET or C#: Which to Choose”), so I can’t tell you yet which one is likely to be more productive. But if it turns out that one language is, in fact, more productive than the other, that will be a major factor in the results.

And the bad code is?

And by the way, it may be time for us to reconsider our definition of “bad” code as well. It’s the beautifully structured, object oriented, “good” C++ code that’s giving us all huge amount of grief due to security problems (buffer overruns, memory leaks, games with pointers, etc.). Barring use of Win32 API calls, VB6 was remarkably immune to all of these problems. Makes you wonder who’s been writing the bad code, doesn’t it?