CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Jeffrey Palermo [MVP]

Software management consultant and CTO, Headspring Systems

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.


Comments

Geoff Appleby said:

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 :)
# February 21, 2006 1:12 AM

Eric Wise said:

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.
# February 21, 2006 8:22 AM

Jeremy D. Miller said:

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.

# February 21, 2006 8:33 AM

Jeffrey Palermo said:

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.
# February 21, 2006 9:28 AM

pvanooijen said:

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





# February 21, 2006 10:53 AM

Eber Irigoyen said:

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
# February 21, 2006 12:54 PM

DonXml's All Things Techie said:

# February 21, 2006 1:49 PM

Jeff Lynch said:

Jeffrey Palermo stoked the fire a little bit in his recent post RAD Kills.
# February 21, 2006 8:41 PM

Peter's Gekko said:

In a pleasantly provoking post Jeffrey warns us against the dangers of RAD. What RAD stands for in his...
# February 23, 2006 6:23 AM

Peter's Gekko said:

In a pleasantly provoking post Jeffrey warns us against the dangers of RAD. What RAD stands for in his...
# February 23, 2006 8:44 AM

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

Some of my CodeBetter neighbors have been posting and arguing about the relative merits of Rapid Application...
# February 26, 2006 9:21 PM

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

[EDIT] Before I start, let me make this very clear.  RAD is not evil, it doesn't kill, and you're...
# February 26, 2006 11:56 PM

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

[EDIT] Before I start, let me make this very clear.  RAD is not evil, it doesn't kill, and for a...
# February 26, 2006 11:57 PM

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

[EDIT] Before I start, let me make this very clear.  RAD is not evil, it doesn't kill, and for a...
# February 26, 2006 11:58 PM

Chris Holmes said:

"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!
# February 27, 2006 1:47 PM

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

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.
# February 28, 2006 8:56 AM

Brendan Tompkins said:

I don’t usually Rant, but this post has been welling up inside of me for a number of months now,...
# March 10, 2006 10:27 AM

Brendan Tompkins said:

I don’t usually Rant, but this post has been welling up inside of me for a number of months now, and...
# March 10, 2006 10:29 AM

James Gibbons said:

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.
# March 19, 2006 1:21 PM

Peter's Gekko said:

Jeff kept the RAD candle burning. May I add some kerosene ? The radrace (most links on the site point...
# March 27, 2006 3:27 AM

Peter's Gekko said:

The term RAD is more or less a hot topic on Codebetter. It started with a "RAD kills" post by Jeffrey...
# April 25, 2006 4:04 AM

Tagroom??? Blog said:

# April 26, 2006 2:37 AM

Brendan Tompkins said:

Using ASP.NET 2.0’s new GridView control with the new ObjectDataSource allows...
# May 11, 2006 4:32 PM

Ayende @ Blog said:

Rad kills

# January 13, 2007 2:27 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

About Jeffrey Palermo

Jeffrey Palermo is a software management consultant and the CTO of Headspring Systems in Austin, TX. Jeffrey specializes in Agile coaching and helps companies double the productivity of software teams. Jeffrey is an MCSD.Net , Microsoft MVP, Certified Scrummaster, Austin .Net User Group leader, AgileAustin board member, INETA speaker, INETA Membership Mentor, Christian, husband, father, motorcyclist, Eagle Scout, U.S. Army Veteran, and Texas A&M University graduate. Check out Devlicio.us!

This Blog

Syndication