Jeffrey Palermo (.com)

Sponsors

The Lounge

News

Recent Posts

Syndication

Tags

View more

Archives

Advertisement

Jeffrey Palermo (.com) » RAD kills. . . software - level 200
Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
RAD kills. . . software - level 200
I figured the title would get someone's attention.  I'd like to share this piece of art that I created. 
By now, everyone has been educated about the dangers of cigarettes and tobacco.  Cigarettes can be addictive and even deadly.  While they may be soothing in the short-term, they ultimately cause irreparable damage. 

I'd like to compare this to the RAD style of development.  RAD is quick and satisfies in the short term.  Sometimes it's amazing how many features can be created just by some dragging and dropping.  You could whip out an entire system in a week.  It's almost too good to be true.

But what about next month, and the month after that?  The attempts at enhancing that system are futile.  You desperately try to get some productivity out of the RAD approach, and you may be able to slap on a new feature quickly, but when you have to modify or enhance an older feature, you can't get the same satisfaction.  It takes forever to debug through to see what's really happening.

RAD is quick, but it incurs huge technical debt.  RAD is like consumer credit.  You can have it now, but will you really have time to clean it up later?  If you buy that big-screen HDTV now, will you really have $3000 extra dollars lying around later?  RAD can be very tempting, but in the end, it leads only to death. . . of your software.  At some point, the only recourse will be a total rewrite.  At that point, will you use RAD again for the rewrite or use another _sustainable_ process?

Orthogonal to RAD is sustainable development:  Creating interfaces at key areas of your system to ensure flexibility.  Adequately testing your software to ensure you don't break old features when you introduce new ones.  Ensuring your software never becomes legacy code, etc.

RAD isn't the answer.  Creating sustainable software takes work and is not for the faint-hearted.  It takes good software (dare I say?) engineers - critical thinkers - disciplined craftsman.

I hope you have enjoyed the satire of this post, but satire can't exist without a grain of truth.
Posted Mon, Feb 20 2006 10:17 PM by Jeffrey Palermo

[Advertisement]

Comments

Geoff Appleby wrote re: RAD kills. . . software - level 200
on Tue, Feb 21 2006 1:12 AM
You know what might help? An actual explanation of what RAD is. What sort of things you do when developing RAD style. If you want to actually convert people with a post like this (and that's fine! i thought it was quite funny) it might be a good idea to let people that don't know that they're giving themselves cancer what is _actually_ giving them cancer.

I was actually going to try and start a fight with you about how it isn't all bad (and that's not to say i disagree with you, but the discussion would be valuable) but I realised that I can't unless i know what you're definition of RAD actually is :)
Eric Wise wrote re: RAD kills. . . software - level 200
on Tue, Feb 21 2006 8:22 AM
RAD is for three things:

1) Proof of concept / Sales Presentation
2) For that tiny niche application that does a very simple thing and doesn't have any plans for continuous expansion.
3) Allowing a complete newbie to feel productive while they gain comfort level with the language/toolset.
Jeremy D. Miller wrote re: RAD kills. . . software - level 200
on Tue, Feb 21 2006 8:33 AM
I can't believe I'm saying this, but...

4) Shadow IT / Customer Supported System / whatever

Allowing a non-programmer in the actual business pick up something like Excel or Access to automate some of their work. Promptly grows into a sphaghetti mess that IT picks up later when it becomes mission critical, but that's a different story.

Jeffrey Palermo wrote re: RAD kills. . . software - level 200
on Tue, Feb 21 2006 9:28 AM
Geoff,
You have a very good point. I didn't define RAD, but I wasn't too serious about starting a RAD preaching series.

I think the two camps are RAD vs. Long-term (or sustainable). One big point would be to spell out why RAD == short-term (write-only, unsupportable, etc).

Part of that would be depending on a GUI designer to write code for you (code that you might not understand). I love code-generators that write exactly the code I would have written anyway. These save me time. I can't tolerate code-generators that write code in a way I don't understand (or like).

Even with NHibernate, I didn't blindly let it generate and run SQL for me. I tapped in with SQL Profiler to monitor the sql it was sending to the database to ensure it was acceptable to me.

RAD often goes hand-in-hand with "programming by coincidence" - read The Pragmatic Programmer.
pvanooijen wrote re: RAD kills. . . software - level 200
on Tue, Feb 21 2006 10:53 AM
In the "old" days when RAD was introduced it also stood for Rapid Application Design. When it comes to designing Visual stuff I still like it very much. Drag and drop the componenets on your form and use the designer to navigate through the code which is attached to the events. Still nice. As well because the user of the software and the developer have the same view on (parts of) the code.

I still like this for non visual "componenets" as well. A component with dataadapters and the like does give a good overview.

But when the developer starts pouring all code in the form/component its quite easy to get the mess you describe. The real code should be quite somewhere else. To be testable, etc..





Eber Irigoyen wrote re: RAD kills. . . software - level 200
on Tue, Feb 21 2006 12:54 PM
as most things in programming, is hard to draw a line where you should stop using RAD and do it by hand

I usually follow some simple rules
- leave the visual part to RAD
- separate the business logic from the RAD (different class)
- don't hardcode properties like ConnectionString, ProcedureName, etc; create a method to load those at some point, this by itself avoids many "it works on my machine"
- don't tie your data (or business specific) functions to RAD components, instead use interfaces so that the "client" (the winform, webform, console, etc) can consume your functions implementing their own way of displaying the data.
This last one makes your code very extensible, you can use your same business object from anywhere you need
DonXml's All Things Techie wrote RAD Kills But Analysis Paralysis Stifles
on Tue, Feb 21 2006 1:49 PM
Jeff Lynch wrote Off Topic: Does RAD Really Kill?
on Tue, Feb 21 2006 8:41 PM
Jeffrey Palermo stoked the fire a little bit in his recent post RAD Kills.
Peter's Gekko wrote How I found RAD
on Thu, Feb 23 2006 6:23 AM
In a pleasantly provoking post Jeffrey warns us against the dangers of RAD. What RAD stands for in his...
Peter's Gekko wrote How I found RAD
on Thu, Feb 23 2006 8:44 AM
In a pleasantly provoking post Jeffrey warns us against the dangers of RAD. What RAD stands for in his...
Jeremy D. Miller -- The Shade Tree Developer wrote On Rapid Application Development and Creating Maintainable Code
on Sun, Feb 26 2006 9:21 PM
Some of my CodeBetter neighbors have been posting and arguing about the relative merits of Rapid Application...
Jeremy D. Miller -- The Shade Tree Developer wrote On Rapid Application Development and Creating Maintainable Code
on Sun, Feb 26 2006 11:56 PM
[EDIT] Before I start, let me make this very clear.  RAD is not evil, it doesn't kill, and you're...
Jeremy D. Miller -- The Shade Tree Developer wrote On Rapid Application Development and Creating Maintainable Code
on Sun, Feb 26 2006 11:57 PM
[EDIT] Before I start, let me make this very clear.  RAD is not evil, it doesn't kill, and for a...
Jeremy D. Miller -- The Shade Tree Developer wrote On Rapid Application Development and Creating Maintainable Code
on Sun, Feb 26 2006 11:58 PM
[EDIT] Before I start, let me make this very clear.  RAD is not evil, it doesn't kill, and for a...
Chris Holmes wrote So true
on Mon, Feb 27 2006 1:47 PM
"Allowing a non-programmer in the actual business pick up something like Excel or Access to automate some of their work. Promptly grows into a sphaghetti mess that IT picks up later when it becomes mission critical, but that's a different story.
"

So true!
Jeremy D. Miller -- The Shade Tree Developer wrote On Rapid Application Development and Creating Maintainable Code
on Tue, Feb 28 2006 8:56 AM
Author: <a href="blogs/Jeremy.miller">Jeremy D. Miller</a><br />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.
Brendan Tompkins wrote Visual Studio 2005... Uggh.
on Fri, Mar 10 2006 10:27 AM
I don’t usually Rant, but this post has been welling up inside of me for a number of months now,...
Brendan Tompkins wrote Visual Studio 2005... Uggh.
on Fri, Mar 10 2006 10:29 AM
I don’t usually Rant, but this post has been welling up inside of me for a number of months now, and...
James Gibbons wrote re: RAD kills. . . software - level 200
on Sun, Mar 19 2006 1:21 PM
RAD can be very tempting, but in the end, it leads only to death. . . of your software. At some point, the only recourse will be a total rewrite.

Yes I agree if you use VB6 or VC and MFC wizards :)

The death/rewrite is more a function of market changes than the tools or their ability to adapt to new functions.

As I see it there are two types of RAD: RAD for GUI and RAD for application specific solutions like LabView, VisionBlox or Active MIL (which I will shorten to ASS). :)

RAD for GUI (having started with Delphi 1.0) has saved me many hours of design effort. If you need to do many custom apps for many customers with different requirements, I only see it as a plus.

RAD for ASS is another entirely different subject. I could use it for my image processing solutions, but it would not give me the control I need. All such ASS solutions tend to take aim at specific problem areas and while they solve those problems they will never address the whole world of things we do.

When used as tools for the specific problems they were designed to solve, I don't see RAD as a problem.
Peter's Gekko wrote Radrace
on Mon, Mar 27 2006 3:27 AM
Jeff kept the RAD candle burning. May I add some kerosene ? The radrace (most links on the site point...
Peter's Gekko wrote RADical ASP.NET in VS 2005 without messing it up right from the start
on Tue, Apr 25 2006 4:04 AM
The term RAD is more or less a hot topic on Codebetter. It started with a "RAD kills" post by Jeffrey...
Tagroom??? Blog wrote Tagroom??? Blog
on Wed, Apr 26 2006 2:37 AM
Brendan Tompkins wrote An ObjectDataSource/GridView Adapter for Business Entity Collections
on Thu, May 11 2006 4:32 PM
Using ASP.NET 2.0’s new GridView control with the new ObjectDataSource allows...
Web Things Considered » To .Net or not to .Net wrote Web Things Considered » To .Net or not to .Net
on Wed, May 24 2006 1:57 AM
Ayende @ Blog wrote Rad kills
on Sat, Jan 13 2007 2:27 PM

Rad kills

dave^2=-1 wrote RAD or Refactor?
on Fri, Feb 1 2008 5:53 AM

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