Peter van Ooijen @ Codebetter.com talked about RAD experience in Visual Studio 2005.  He does a great job of highlighting useful features and also provide gotchas that developers should be aware of.  By the way, if your job involves writing software and if you are not subscribed to Codebetter.com's RSS feed, now is a great time to do it.  It's full of great tips and discussions that every software developers should read.

My team is currently in a final planning phase for Orcas (next version of Visual Studio).  Since Orcas is no different from other software projects, there have been a lot of hard decisions being made.  We would like to make sure that we ship the right stuff with right quality and not miss the date.  Anyway, one question I am trying to answer is "How much RAD experience should we provide?"  Visual Studio 2005 has made a giant leap in terms of enabling developers focus on solving real business problems without being bothered by all the mundane tasks.  You can literally create a data-driven application with master-detail view without writing a single line of code.  Although it's hard to believe why anyone would ship applications created this way, it's a great starting point for developers creating data-centric applications.  Naturally, people would expect this RAD experience to improve in next release.  Think about the history of Visual Studio from RAD point of view.  Every release has provided better RAD experience.

But how far should we go?  One of Visual Studio's goals is to help developers boost their productivity.  But another critical goal of Visual Studio is to help developers create right software in right ways.  It's a goal for all developer tools.  That's why Visual Studio has features like Refactoring and Unit Testing.  I agree that we can do a lot better in these areas.  But at least we acknowledge that we need to help developers create right software in right ways.  The problem is that balancing between RAD experience and helping developers do the right thing is always hard.  Good developers spend a lot of time learning new techniques and studying best practicies.  Design Patterns, security, performance, reusability, etc.  And if these developers have to fight with the tool to apply what they have learned since the tool keeps trying to act like it knows what the developer is trying to do and how to do it best, then these developers will eventually abandon the tool.  That's exactly why I am thinking about "How much RAD would annoy you" question.

It's a hard quesiton and it will take sometime for me to answer it (or maybe I will just keep asking and never come to a conclusion).  Maybe we will try different approaches in each version.  And if we see people like Peter van Ooijen keep writing article about how to work around our RAD features to do the right thing, we would know that we are not really helping developers.

Update: Forgot to mention that I agree with Peter on how bad it is for us to embed SQL statements in markup code.  I am sure folks over at ASP.NET Tools have heard it many times already.  This is a great example of RAD focused approach invading developer's pride.