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