I got into an interesting discussion today about that recently published Comparing Microsoft .NET and IBM WebSphere/J2EE report. If you haven't read it, there's a summary at eWeek, but I definitely recommend downloading the full report for the details. If you're too busy to do either of those things, well, I'll just tell you: in this particular study, VS.NET is about twice as productive as either of the two IBM J2EE environments, at approximately one-tenth the cost. It's also slightly faster and performs more reliably, but after the key productivity and cost results, those things are just icing on the cake.

This is significant enough that I felt like sharing it with a few fellow developers and some management. Predictably, I got some pushback from some of the Java oriented developers: "Well, what do you expect from a Microsoft commissioned report." I don't consider that a valid criticism. Microsoft didn't conduct the study, they just commissioned it. And the report has this disclaimer on the third page:

1.4 Does a "sponsored study" always produce results favorable to the sponsor?

No.

Our arrangement with sponsors is that we will write only what we believe, and only what we can stand behind, but we allow them the option to prevent us from publishing the study if they feel it would be harmful publicity. We refuse to be influenced by the sponsor in the writing of this report. Sponsorship fees are not contingent upon the results. We make these constraints clear to sponsors up front and urge them to consider the constraints carefully before they commission us to perform a study.

Disregarding the report sight unseen because Microsoft sponsored it is like disregarding someone's opinion based on their ethnicity:

Of course we expect that from Bob, he's an Eskimo. And everyone knows Eskimos are liars!

If you want valid criticisms, you have to disagree with the actual substance of the report. So after actually reading it (one would hope) this is the criticism I got back from a fellow developer:

Visual Studio, like Visual Basic and other Microsoft development tools and languages, provide ease of use and a low learning curve at a price: They don't impose any kind of discipline or framework, making it too easy to crank out poorly designed apps and horrid code. This is not helped by all the amateur Visual Basic/Studio "developers" out there who have no understanding of basic comp sci concepts. (Luckily, we don't hire those kind of developers, but I'm sure we've all worked with many of them in the past.)

On the other hand, J2EE by its nature imposes some rigid rules and forces one to use some kind of a framework to deliver an enterprise level app. This takes more time, planning, and skill. As a result, though, J2EE apps, by comparison, tend to be more robust, maintainable, and scalable. This is not to say that .NET apps cannot have those qualities as well -- it just takes a lot more discipline and some self-imposed rules to achieve this -- Visual Studio doesn't give you that out of the box.

Obviously, I think this is a complete load of crap. Consider all the projects you've worked on in your career as a software developer. At any point in any of those projects, can you ever remember saying to yourself:

Developing applications is far too easy! If only my development could be made more difficult and challenging!

Dan Appleman also refutes this ridiculous argument in one of his blog posts:

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.

What I find amusing is that someone would actually try to invert this argument, proposing that bad tools are good because they force you to produce better code. And if they don't, well-- that's because you aren't smart enough to use them correctly, stupid!