[EDIT] Before I start, let me make this very clear. RAD is not evil, it doesn’t kill, and for a very common class of applications it is both appropriate and efficient.
Some of my CodeBetter neighbors have been posting and arguing about the relative merits of Rapid Application Development. There was also quite a bit of internal discussion, part of which was to stop being so opinionated in the blog posting and get back to technical posts. Let me get this one out of the way, then I’m back to coding.
- Jeffrey satires RAD
- Peter van Ooijen celebrated RAD
- Jeff Lynch had a reductio ad absurdum post on RAD
What is this “RAD” you speak of?
Part of the problem is a mismatch in meaning and attention. There’s a bit of a false dichotomy out there that you’re a “drag’n dropping” Mort or some sort of aberrant Einstein writing everything in Assembler code. By no means would I ever recommend that you dump the visual designer for WinForms to create the view code, but I’d strongly recommend against using data aware widgets if there’s any business logic involved.
My definition of Rapid Application Development (there is a full blown process called Rapid Application Development out there that sounds a lot like Agile without the enabling practices like TDD and CI) is the reliance on visual designers and coding wizards to create software with minimal coding, often with data aware screen widgets. It’s a perfectly good way to create little bitty applications that merely provide a thin wrapper around relational database data, and there’s a tremendous value out there in being able to slap together these kinds of applications in a hurry. I got my start in programming doing just this very thing for little applications that my engineering team used. You could even make the claim that RAD enables business users to build their own applications (that’s a horror story for a different day).
However as soon as any kind of nontrivial business logic is called for, RAD quickly shows its limitations. Creating an application by dragging and dropping data aware UI widgets onto the visual designer with business logic embedded in event handlers in the screens every which way is a maintenance nightmare. Event driven code is one of the nastiest things in the world to debug and understand. Neal Ford of “No Fluff, Just Stuff” fame already has a good post on the limitations of RAD: Technology Snake Oil, Part 2: RAD. I’ll sum it up for you with one quote: “RAD development doesn’t scale well”.
Software without Coding, or More Productive Coding
Let’s back up to first causes and look back at the ever present perceptions of software development that brought about Rapid Application Development in the first place.
- Software development is too hard and fraught with risk and failure
I feel like there has been two diametrically opposed approaches to improving software development efficiency. In one camp is the people trying to create ways of doing software development without coding. Thus drag n’drop UI wizards ala VB6 and PowerBuilder, the CASE tools fiasco of the 80′s, and the current Model Driven Architecture approach. I’m extremely dubious about MDA (but if it succeeds I’ll jump on board) and downright disdainful of Executable UML, but time will tell. At this point I think we can safely say that pure drag’n drop RAD approaches are only effective for simple applications and move on to approaches that lead to sustainable development.
The other school of thought is to try to make coding easier and more reliable. Languages like the .Net languages and Java are “softer,” they accept changes much more readily than C++ or other older languages. Dynamic languages like Smalltalk, Python, and Ruby may end up being much better on this score. Test Driven Development does more than anything I’ve ever used to create code that is easy to change, both because of the comprehensive unit test coverage and the loose code coupling that TDD requires. Automated refactoring tools make coding simpler by reducing the mechanical cost of improving and changing code. Design patterns provide design shortcuts. Code smells and anti-patterns help us steer away from possible maintenance issues later.
Looking forward, I’m interested in seeing how Domain Specific Languages, Language Oriented Programming, and Intentional Programming impact software development. I’m also reading a lot lately from folks looking way back to functional languages like Lisp to create a more productive coding experience by working at a higher level of abstraction.