in Search

Do you Twitter? Follow us @CodeBetter

Jeremy D. Miller -- The Shade Tree Developer

Under the hood and working with .Net, TDD, Software Design, and Agile Stuff

On Rapid Application Development and Creating Maintainable Code

[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.

Published Feb 26 2006, 08:18 PM by Jeremy D. Miller

Comments

Chris Hanson said:

Rapid Application Development scales very well, so long as you're using a great framework and tools, like Cocoa on Mac OS X. Here's a quick rundown of why Cocoa works so well relative to the kinds of RAD environments you're talking about above.

First of all, Interface Builder doesn't generate code, it generates serialized object graphs. All of the code to instantiate your user interface is already in the Cocoa framework, and in any custom view classes you've written, so why generate anything other than data that can be used to drive that code at run time? Not only is there less code for you to maintain, new features can come for free when Cocoa is enhanced. (For example, in Mac OS X Tiger, you can look up the definition of any word in a text field in the dictionary. No code change required on developers' part.)

Secondly, the framework handles events for you in the vast, vast majority of cases. You can focus on how your controls are supposed to interact; you don't write low-level event handlers or dispatchers when you're working with Cocoa. You write action methods that you tell your controls to invoke on a target, or on the (well-defined) "responder chain." Controls already know how to do things like respond to mouse tracking.

Finally, instead of "data aware widgets" Cocoa has Key-Value Coding, Key-Value Observing, and Bindings. These let you navigate object graphs, observe changes in object graphs, and connect your user interface to your model objects through reusable controllers, respectively. They are very flexible and very useful in applications of all sizes; they don't fall down as you scale an app up. These days I wouldn't want to build an application without it.

And then there's Core Data, which significantly enhances the kinds of model objects you can create out of the box using Cocoa. Automatic undo and redo support and object graph persistence? It's in there, and it's designed to leverage the rest of the Cocoa technologies.

Really, a lot of your criticism of RAD is addressed very well the technology in Cocoa on Mac OS X today. It's worth checking out.

# February 26, 2006 10:10 PM

David Hayden said:

I think you are speaking to the choir, Jeremy. We get it.

Many of the people using drag-and-drop, declarative data sources, table adapters, etc. may be building 2-layer database-driven applications with almost no business rules. These types of applications do exist so let's stop beating the hell out of people who might be using these technologies for these reasons.

Although I am right there with you on using MVP, TDD, design patterns, and various OOP for applications that would benefit from such practices, there are also applications where such practices would be incredibly overkill, introduce needless complexity, increase maintenance and support costs, etc.

I think the posts in response to Jeffrey's post were just saying that such a broad generalization, satire or not, is just one perspective on development. A whole class of other developers are probably successfully and intelligently using the built-in RAD functionality within Visual Studio, etc. for either a different class of applications or different parts of an application.

To write-off all the RAD capabilities of Visual Studio as a whole is just plain silly. Tabulate the pros and cons of each RAD feature and use them appropriately.

# February 26, 2006 11:28 PM

Jeremy D. Miller said:

David,

I really didn't mean to say throw all the RAD and visual designers in VS away. I *did* say that RAD was perfectly acceptable for simple apps with little or no business logic.

As for preaching to the choir, yeah, I think we're just about done here.

# February 26, 2006 11:41 PM

Aaron Robson said:

Hi,
I've been ranting about this stuff for a while now with regard to asp.net. Check out my aspnet is for dummies post on my blog:
http://intrepidnoodle.com/BlogViewArticle.aspx?m=ShowArticle&articleId=12

(I hope the horrible url works!).

# February 27, 2006 4:20 AM

pvanooijen said:

Your point is absolutely valid.

But my objection is still to call just that RAD. In a part of the history of those three letters part of "RAD" was the dreaded data-widget practice. But imho RAD covers far more than that...

# February 27, 2006 9:21 AM

Jeremy D. Miller -- The Shade Tree Developer said:

I think everybody and their little brother has seen Jeffrey and Scott's posts bashing the MS personas...

# April 28, 2006 4:25 PM

dave^2=-1 said:

Found this old, satirical post by Jeffrey Palermo. It reflects one part of a train of thought I have

# February 1, 2008 5:53 AM

Name (required)

Your URL (optional)

Comments (required)

Remember Me?

Enter the numbers above:

Add

About Jeremy D. Miller

Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy previously worked as a systems architect building mission critical supply chain software for a Fortune 100 company and learned agile development practices as a .Net consultant at ThoughtWorks, one of the pioneers of agile development. Jeremy is the author of the open source StructureMap (http://structuremap.sourceforge.net) tool for Dependency Injection with .Net and the forthcoming StoryTeller (http://storyteller.tigris.org) tool for supercharged FIT testing in .Net. Jeremy's thoughts on just about everything software related can be found on his weblog "The Shade Tree Developer" at http://codebetter.com/blogs/jeremy.miller, part of the popular CodeBetter site. Jeremy is a Microsoft MVP for C#.

This Blog

Home
Contact

Syndication

News

All opinions expressed here constitute my (Jeremy D. Miller's) personal opinion, and do not necessarily represent the opinion of any other organization or person, including (but not limited to) my fellow employees, my employer, its clients or their agents.

About Me

"Best Of" Compendium

StructureMap (Dependency Injection for .Net)

StoryTeller (Supercharged Fit)

Build your own Cab