What does RAD really mean?
Author
I admit that I have limited experience with RAD, however I am starting to think that it means Really Atrocious Design.
Does Rapid Application Development have to mean that you throw design out the window and spit out code until the system "works"?
Or is RAD the use of code generators and random hacks to fix the parts that don't quite fit into the template?
I don't know if the idea of RAD actually works well anywhere, but from my impression it isn't the way to go about building a system that you want to last. It also doesn't seem like a sustainable way to continue improving an existing project.
Of course, it does sound catchy and what bean counter in their right mind doesn't prefer quick results over slow ones?
"Rapid Application Development" really can mean anything you want it to mean. Generally however it refers to making heavy use of tools and frameworks to get things done more quickly. It doesn't mean you have to throw good practices and good design principles out of the window... although I must admit that the term is often used that way.
If you want a good example of an IDE that promotes RAD style principles, check out Borland Delphi. At least for UI-heavy applications, it doesn't get any easier than this.
If you want a good example of an IDE that promotes RAD style principles, check out Borland Delphi. At least for UI-heavy applications, it doesn't get any easier than this.
Author
I just want to know how to convince my co-workers that RAD isn't an excuse for bad design. I'm tired of hearing "but we only have so much time, and certain things have higher priority."
Rapid Application Development doesn't mean "you don't have to concentrate on design". Just the opposite. Rapid Application Development means "you can concentrate solely on design". And people who think that good design takes longer than bad design are ignorant about the fundamentals of software development. That's not to say that BDUF is the only way to go, but a good design strategy of some sort is job 1 for any successful development project.
Author
I guess the real issue is that when you have millions of lines of legacy code to wade through, people aren't very receptive of change. I find myself often having to put a sock in my mouth to keep the suggestions about design, loose coupling, or OOP from slipping out... All I do is sound like the naive new guy :( Not that the others disagree with design, they just want me to be "rapid."
The guy who fixes 3 bugs a day (that's rapid) is probably going to look better than me when I pump out 1 fix a week (that's slow) but produce code that plugs potential holes and leaves room for practical reuse (which I determine by looking at what we have and what we need). At least I'm fixing the bugs that are labeled to be "hard." I sure hope I'm going about things the right way.
Although my next task will be creating something new so maybe I'll get to show the value of good design.
The guy who fixes 3 bugs a day (that's rapid) is probably going to look better than me when I pump out 1 fix a week (that's slow) but produce code that plugs potential holes and leaves room for practical reuse (which I determine by looking at what we have and what we need). At least I'm fixing the bugs that are labeled to be "hard." I sure hope I'm going about things the right way.
Although my next task will be creating something new so maybe I'll get to show the value of good design.
Quote:Original post by T1Oracle
I just want to know how to convince my co-workers that RAD isn't an excuse for bad design. I'm tired of hearing "but we only have so much time, and certain things have higher priority."
RAD isn't an excuse for bad design, but unfortunately deadline pressure tends to be in a business environment. And realistically, you're going to lose money if the stuff doesn't get done on time. The proper argument is trying to convince them that they're losing more money (in manpower/maintenance/loss of repeat sales) because of the shoddy design.
Easier said than done.
RAD (rapid application development) is a concept that products can be developed faster and of higher quality through:
* Gathering requirements using workshops or focus groups
* Prototyping and early, reiterative user testing of designs
* The re-use of software components
* A rigidly paced schedule that defers design improvements to the next product version
* Less formality in reviews and other team communication
Some companies offer products that provide some or all of the tools for RAD software development. (The concept can be applied to hardware development as well.) These products include requirements gathering tools, prototyping tools, computer-aided software engineering tools, language development environments such as those for the Java platform, groupware for communication among development members, and testing tools. RAD usually embraces object-oriented programming methodology, which inherently fosters software re-use. The most popular object-oriented programming languages, C++ and Java, are offered in visual programming packages often described as providing rapid application development.
* Gathering requirements using workshops or focus groups
* Prototyping and early, reiterative user testing of designs
* The re-use of software components
* A rigidly paced schedule that defers design improvements to the next product version
* Less formality in reviews and other team communication
Some companies offer products that provide some or all of the tools for RAD software development. (The concept can be applied to hardware development as well.) These products include requirements gathering tools, prototyping tools, computer-aided software engineering tools, language development environments such as those for the Java platform, groupware for communication among development members, and testing tools. RAD usually embraces object-oriented programming methodology, which inherently fosters software re-use. The most popular object-oriented programming languages, C++ and Java, are offered in visual programming packages often described as providing rapid application development.
Author
Quote:Original post by Telastyn
The proper argument is trying to convince them that they're losing more money (in manpower/maintenance/loss of repeat sales) because of the shoddy design.
Easier said than done.
I'm trying, but it is an uphill battle.
@israel90
OOP isn't any more reusable, it does lend to clearer code organization and it can greatly reduce code repetition. You only get reusability if you design for it. Even then, your reusability can go wrong if you make the wrong predictions (which is common unless you're following "prior art").
I tend to see RAD as more of a way to change applications quickly. At my work we use a well defined engine-like structure for all the C++ math and physics code, but Visual Basic.NET for the front end GUI. Why? because its a lot quicker to change when a customer asks it to be changed to do XYZ.
Sure it could be also written in a well defined manner and good design could be applied, but only until it needs to be changed again. Also there never tends to be the resources (read: people and time) to change it over.
Sure it could be also written in a well defined manner and good design could be applied, but only until it needs to be changed again. Also there never tends to be the resources (read: people and time) to change it over.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement