Rapid Application Development (RAD)

I'm of two minds about putting up a page in the DevRoadmaps Wiki for RAD.

On the one hand, this part of the site is for general development topics including more traditional and usually hand coded approaches to business application development; RAD is more often the province of tools like Clarion and WinDev, both of which have their own spaces here. 

On the other hand (and both hands are coding), tooling for non-RAD development has over the years become decidedly faster. Commonly-needed functionality becomes commoditized; languages become more expressive; IDEs provide better support for code management.

Mark Goldberg recently pointed out one such code management tool: Code Canvas:

Code Canvas is a new user experience for Visual Studio 2010 that provides an infinite zoomable surface for software development. A canvas both houses editable forms of all of a project’s documents and allows multiple layers of visualization over those documents. By uniting the content of a project and information about it onto a single surface, Code Canvas is designed to leverage spatial memory to keep developers orient-ed and to make it easy to synthesize information.

Check out the YouTube video.

I expect that for many smaller teams tools like Clarion and WinDev will remain the preferred option for years to come. But for larger teams, or for smaller teams with a lot of skill in object-oriented programming, there are some compelling reasons to consider the hand coding approach. (In fact, hand coding these days often does include code generation via T4; it's just not application-scale code generation.)

Two productivity curves that meet

RAD tools provide a ready-made application framework into which you plug your custom code. You're productive very quickly; however, if your application (or set of applications) becomes very large maintainability may in fact become more difficult. In the case of WinDev and Clarion this is largely because of the temptation to put business logic into embed points where it is difficult to test and reuse. 

In a traditional coding environment you're not as immediately productive, but if you have the right team you can build a more testable, reusable code base. Down the road maintenance becomes significantly easier because you have a full suite of tests that continuously validates your code. You also have many smaller, more reusable components. 

Which is better? 

For smaller teams and quick delivery, RAD tools have the advantage. As the application grows in size and complexity, that advantage begins to diminish. In my opinion (I don't have hard data to back this up) the longer the time frame, the more code is involved, the more likely it is that at some point the productivity of the hand code approach will approach and possibly exceed that of the RAD approach. And the code quality will most likely be higher. 

There is one important caveat: you need a higher level of skill to pull off the traditional approach. You need people with good object-oriented programming skills, you need application designers not just coders, you need a high degree of automated testing and continuous build integration so you can track the state of your code. 

The hybrid approach

It's also possible to blend the two approaches: there's no reason you can't separate your business logic into testable, reusable classes, and then call those classes from embed points. In this middle path you still get many of the RAD advantages, although your upfront investment is greater.