Talk:Rapid application development

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Software (Rated Start-class)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Software.

Isn't there also an Interface Builder for Mac OS X?

Rapid application[edit]

== == == Advantages and disadvantages == == ==


Rapid Application Development has two primary advantages: increased speed of development and increased quality. The speed increases are due to the use of CASE tools, the goal of which is to capture requirements and turn them into usable code as quickly as possible. Quality, as defined by RAD, is both the degree to which a delivered application meets the needs of users as well as the degree to which a delivered system has low maintenance costs. RAD increases quality {| class="wikitable"

|- through the involvement of the user in the analylsis and design stages |}.

RAD has two primary disadvantages: reduced Scalability, and reduced features. Reduced scalability occurs because a RAD developed application starts as a prototype and evolves into a finished application. Reduced features occur due to time boxing, where features are pushed to later versions in order to finish a release in a short amount of time.

Compared to what ? To the waterfall model ? Is there anything that woueld suggest the waterfall is any more scalable or results in programs that have more features ? Taw 21:09, 18 February 2006 (UTC)

Compared to the Waterfall model but more directly to traditional non-agile methodologies like SSADM (Structured Software Analysis and Design Model). As far as I understand, RAD (being a methodology) isn't really comparable to the Waterfall model (which is more of a software development life-cycle), the article should probably be changed to reflect this. Although I'm not totally sure so I'll leave the change for someone who has finished their Computer Science Degree :)
The waterfall model / SSADM is more scalable because 1) RAD isn't suited for very small projects, but mainly 2) It requires an unnecessary large amount of overhead for extremely large projects where the requirements are well defined with little ambiguity. RAD also can theoretically mean a product with less features 1) because the increase in managerial overhead may mean less time to spend implementing new features and 2) because features are more likely to be dropped from RAD due to it's emphasis on time boxing and avoiding project duration over-runs (so it's arguable the additional features would only be implemented in SSADM because the project is forced to run over-time to implement those features wheras in RAD, the customer would have the ability to drop the features to avoid the time over-run). Canderra 04:49, 8 May 2006 (UTC)

An what about "Pro: Decreased end-user functionality" ? I'd say that's a definate CON .. not a pro —Preceding unsigned comment added by (talk) 06:11, 13 September 2007 (UTC)

I don't understand this Con. _What data?

  1. The data needed should already exist —Preceding unsigned comment added by (talk) 15:59, 16 January 2008 (UTC)

RAD is scalable and reduced features...TRUE ANYMORE![edit]

Modern RAD tools now has the richest features and the most scalable.

RicoWiki 01:13, 26 June 2006 (UTC)

 rap model is

Stub status[edit]

I think this article isn't really a stub anymore?

Jaapvstr 10:11, 13 September 2006 (UTC)

I don't know, that's such a subjective thing... — Frecklefoot | Talk 15:23, 13 September 2006 (UTC)
Is subjective, but.... few would disagree that it is nolonger a stub now. Mathmo Talk 23:41, 8 May 2007 (UTC)

First language?[edit]

What was the first langauge to employ RAD techniques? Mathmo Talk 23:40, 8 May 2007 (UTC)

What the hell is it?[edit]

The more webpages I find talking about RAD, the more it sounds like a buzzword (just like Web 2.0). Here I see pros and cons, history, more on why it's useful... but not what it is. What, a programmer is supposed to buy a book to know "how to program using RAD"??

RAD is not a way of programming (it's not like OO or procedural). It's a way of making software. Before RAD, requirements were analysed, alternative designs were considered, a detailed specification was implemented, then tested then it usually went back to an earlier stage and worked its way back up towards a finished solution. Since RAD, the implementation (programming) begins earlier in small chunks (usually forms, but could be modules or libraries or components). A RAD tool like VB or Delphi allows you to create a screen with functionality quickly (hence "rapid"). Most screens don't really need a detailed specification and having an analyst write a spec for a programmer to type into the IDE is over-kill. RAD is a methodology (fancy word meaning "way") to create software quickly. It favours programmers who can analyse, design and implement at the same time (in the full knowledge that the initial version won't be perfect and won't be released). Rather than spending months writing a massive spec (that is hardly ever perfect anyway), just start coding and use your stumbling blocks as opportunities to re-examine your design, then recode. For example, using older methodologies a particular project might take 3 months to produce a spec, then 2 months of coding, 1 month of testing (only to find out it's not good enough) then it will go back to the specification for another month then coding for another month then more testing for another month (total of 9 months). With RAD, you could produce a basic spec in 1 month, code for about 2 months, discover that something isn't quite right yourself (you test your own code as you write it and others can review your work regularly), code for another month then pass it on to formal testing (by someone else) and let's say it comes back to you for another month of re-coding then another month of formal testing (project complete in 7 months and you didn't need the services of a glorified cut&paste specialist - that's the over-paid analyst who's lost their techncal skills because technology has moved on and they couldn't keep up). RAD saves time and money and requires programmers who are "software engineers" rather than specification translators and syntax experts! I hate working on specs that have been produced by people with lower technical aptitude, it's called the analysis phase but really it is just trying to stop me from doing my own analysis which I must do in my head while I'm programming anyway because the spec is never adequate (and if it was, I'd be just a typist). (talk) 04:03, 22 May 2009 (UTC)

You open up a number of interesting topics. Let's begin with a couple of definitions:
A professional who can analyse a problem and design a solution as well as programming software
A professional who can communicate with senior stakeholders as well as technical colleagues, who can look at the underlying issues behind a problem and seek to address those with the business before tying up the precious developer resources
If you are working with analysts who are nothing more than glorified requirements secretaries, then I can understand your frustration, however a fully competent analyst will be able to do so much more, supporting and facilitating the work of the developer.
Secondly, RAD is on a continuum from the original structured waterfall approaches to the more recent iterative, extreme programming, and scrum approaches. RAD is not a silver bullet. If the developer does analysis in their head without proper consultation with the business, you may get quality software, but will it resolve what the business needs? This can result in gold-plating, a common risk in projects where developers work without oversight for long periods of time. Which brings me to ...
Lastly, these days, what business can afford to wait 7 months for the first working version of a system to be delivered? It's much more about releasing working software, frequently, in small increments (typically 4-6 weeks), working directly with the product owner and other delivery colleagues.
Postscript: Good analysts can come from a busines or a technical background, and make the decision consciously to work in this space. It's not second best if we cannot hack the code any more. I choose to earn my living primarily by working with business leaders to help them realise their objectives through effective strategies and use of systems. It's what I get a buzz from. I was an analyst/programmer (the original name for developers), which is where I earned my nickname (grey skinned boy) and from time-to-time, I still develop in .NET, PHP, ASP, etc. If I didn't value intrapersonal communication, business improvement, and running training courses so much, I would probably still be coding. Greyskinnedboy (talk) 01:05, 26 May 2009 (UTC)

Plenty of projects take 6 months, 12 months, 18 months... 4-6 weeks (what are you talking about - a modification to an existing system or just a website?). I used to work at a large bank where analysts went on business lunches to discuss "requirements" then a couple of months later they gave us (the programmers) a word document that didn't relieve me of having to do significant analysis myself. And then when I did it and the project went ahead and it was implemented with minimal fuss, those same analysts got together for a nice lunch to celebrate their cut-and-paste skills. Analysts are threatened by RAD, and business clients keep falling for the hype of IT-literate analysts with the gift-of-the-gab (plus exceptional Ctrl-C Ctrl-V skills) - who will ever forget what the analysts said would happen because of Y2K? That's OK, two can play that game, maybe even three. (evil laugh). (talk) 04:54, 17 June 2009 (UTC)

More Pro and Con commentary[edit]

On 5 February 2008 Gingerbits (talk) added this Pro:

End Users relate better to something tangible: as opposed to a written specification. Early visibility of even a mock up application can highlight differences between what End Users thought they wanted. or were going to get, and the reality being developed. Gingerbits (talk) 17:40, 5 February 2008 (UTC)

and these commentaries on the following Cons:

Reduced features occur due to time boxing when features are pushed to later versions in order to finish a release in a short amount of time
This is not always a Con (see 2. above). Time Boxing causes End Users to concentrate on what they need the most. Without this focus 'nice to have's' can creep into the solution and then are often never used. Gingerbits (talk) 17:40, 5 February 2008 (UTC)
The data needed should already exist.
This is not a prerequisite but does represent an issue. More problematic is complex data structures or high transaction volumes. In these both of these cases the database design needs to be fine tuned which means A. The prototype application has to be changed to work with the new schema and B. efficient database design takes time - negating some of the value of a RAD approach. Gingerbits (talk) 17:40, 5 February 2008 (UTC)

Seeing as he signed the edits I've assumed they're opinion (even though I agree with them) and undone the edits in the article. Mark Hurd (talk) 08:50, 7 February 2008 (UTC)

The statement: "Agile methods produce very little written documentation and require a significant amount of post project documentation." seems to me controversial. The idea is surely to avoid unnecessary documentation, not to deliver a system which lacks documentation which is necessary, requiring post-project work. Dominic Cronin (talk) 09:20, 21 August 2009 (UTC)


Is this really just only a methodology? It's a life cycle model... Todadot (talkcontribs) 15:14, 9 March 2009 (UTC)

"Relative effectiveness" table[edit]

These are views that I've seen advanced, but they're far from the only ones on certain of those types. Wouldn't this be solved better by prose than a seemingly-authoritative table that's referenced to nothing? Seraphimblade Talk to me 00:39, 27 February 2011 (UTC)

Criticisms: Programmers GUI driven?[edit]

It would be nice to see some references for these claims cited. In my experience, programmers are generally terrible with GUIs, or UIs in general. More commonly when my colleagues or I see a terrible UI, we always comment that a programmer probably designed it. And I say this as someone who can program.

Whether anyone agrees with this or not, it would still be nice to see some references in that section if people are going to make claims about phenomenons in programming. Rohaq (talk) 01:25, 22 April 2011 (UTC)

This article is simply and totally wrong![edit]

For the very simple reason that RAD is just not what is said in this article.

There is in fact in the literature (since the late 80's at least) a prototype-based software process, where the prototype is meant to facilitate the requirements definition, then it gets discarded to start building the real product now with all the good practices in place. On the other hand, RAD is just something else: it is a sequential process model with a very short cycle, namely a "quick waterfall", and not only it can only work when there is a good base of reusable components, it also has all the problems (and, should I say, the very well known problems) of tools-based development, i.e. as a long-term development strategy it is a sure technical suicide.

This article should be completely rewritten by someone who knows what s/he is talking about and who has nothing to sell. Otherwise better just delete it, which I will definitely do in a week from now, unless some discussion starts and someone commits to rewriting something decent enough.

LudovicoVan (talk) 21:22, 24 November 2011 (UTC)

There is no justification for deleting this article. --Boson (talk) 09:22, 9 May 2012 (UTC)
Agree absolutely there is no way this article should have been considered for deletion, at most it could have been reverted to a stub. I've essentially rewritten the article since LudovicoVan wrote that comment about how bad the article was (I agree it was bad). Of course I think I know what I'm talking about but we'll see what others think ;-) --MadScientistX11 (talk) 14:52, 2 July 2014 (UTC)

What Happened to the Original Meaning of the Term RAD?[edit]

In the early 90s the term Rapid Application Development was most often used to refer to semi-automated software development processes where the developer would essentially create the application by selecting options offered by an expert system. One such system shipped with at least one of the DOS versions of Borland's Paradox (RDBMS system), and similar solutions were offered by other RDBMS vendors at the time. This method at least deserved to be called "rapid". Surely there should be mention of this or perhaps it should have its own entry? — Preceding unsigned comment added by (talk) 01:23, 9 May 2012 (UTC)

I don't agree that this was the "original" meaning of RAD. I was using the term RAD before the Borland system you mentioned was built. In fact we always said that we practiced RAD when we built any expert system. I worked for a big 5 consulting firm and was always getting pressure to use the official waterfall methodology which I hated with a passion. It's an unfortunate fact of the IT world that various vendors (Borland, IBM/Martin) try to "own" words like RAD. I agree though that more information on tools like the Borland product would be valuable, I think it would make a good addition to the current article and encourage you to add it. --MadScientistX11 (talk) 14:48, 2 July 2014 (UTC)

Rapid development vs. RAD[edit]

Since more and more places are using the term "rapid development" and it has no definition (other than a pointer to RAD), I suggest creating an article on Rapid development and separating out James Martin's RAD as the historical background (and more of a life-cycle model than a methodology). Rapid development can be seen as a methodology... but very loosely defined. I think it should be inclusive of other methodologies such as XP.

For instance, List of graphical user interface builders and rapid application development tools has a whole bunch of frameworks that never mention RAD, but simply "rapid development".

Benjamin Bach (talk) 12:48, 17 June 2013 (UTC)

You can really tell a person's IT background by how they use terminology like this. People steeped in Mainframes and COBOL tend to have read a lot of Martin and by RAD mean Martin's RAD. People like me who don't have a very high opinion of Martin and who worked more in the Unix, OO, and AI worlds use the term RAD and are surprised when people think we are talking about James Martin. Sorry, that was a bit of a tangent, back to the point I agree with your criticism but I felt that there wasn't enough well sourced material in the article at this point to justify splitting off two articles, one for RAD in general and one for Martin but what I tried to do in my recent changes was be very clear when the article was talking about RAD in general and when it referred to Martin's approach. --MadScientistX11 (talk) 14:42, 2 July 2014 (UTC)

Jepoy ??[edit]

What does RAD Jepoy mean ?Kesstrelle (talk) 19:21, 29 November 2013 (UTC)

Removing Table in Pros and Cons section[edit]

There is currently a table in the pros and cons section of the article. The table has no references and it is confused and wrong in some places. For example, it talks about Agile and Extreme Programming as if they are two different things when in reality they are simply two different words for the same approach. It lists "Scrum" as another alternative methodology. While there are some things on the Internet that bolsTer this, I see some people talk about the Scrum approach, in the Agile community a scrum is one of many techniques used in Agile, not an alternative to Agile. As an example of something that is just plain wrong the table says this: "Short iteration may add too little functionality, leading to significant delays in final iterations. Since Agile emphasizes real-time communication (preferably face-to-face), using it is problematic for large multi-team distributed system development." Large multi-team systems are difficult to develop with any methodology but Agile can be used for such projects. I've seen it used for them several times and there are plenty of documented cases. Since the table has no references at all and is so confused I think it's best to just remove it rather than try to tweak it which is what I'm going to do now. --MadScientistX11 (talk) 15:22, 21 June 2014 (UTC)

Yes check.svg Done --MadScientistX11 (talk) 16:27, 1 July 2014 (UTC)

Four Phases of RAD: Reference?[edit]

Currently there is a section titled "Four Phases of RAD". There are no references for this section. I think we need to distinguish better between Rapid Application Development (RAD) as a general approach vs. RAD as the name of the Martin methodology. In this comment I'll call RAD as a general term RAD1 and the Martin method RAD2. I'm very familiar with RAD1 but not so much with RAD2. I think it's wrong to list four phases (regardless of what name one picks for the phases) as THE phases for RAD1. RAD1 can be Agile, it can be spiral model, it can be RUP, etc. The phases for RAD1 will depend on which version of RAD1 one picks and in some Agile versions the whole notion of lifecycle phases is downplayed or eliminated all together. I'm assuming that the four phases here are the main phases of RAD2? I'm going to do a bit more research to see if I can verify that. I'm tempted to just remove this whole section since there are no references. Anyone have an opinion? --MadScientistX11 (talk) 23:17, 23 June 2014 (UTC)

I found this paper: It lists the phases of RAD2 and they are not the same as in the article. I'm just going to remove that section. --MadScientistX11 (talk) 23:21, 23 June 2014 (UTC)
I got hold of the James Martin book and now I see where those phases came from. I put them back in and documented the appropriate pages in Martin's book. I added a sentence to make it clear that these are not by any means the only ways to do RAD in general but rather the names for the phases in Martin's approach. --MadScientistX11 (talk) 23:14, 30 June 2014 (UTC)
Yes check.svg Done --MadScientistX11 (talk) 14:36, 2 July 2014 (UTC)

History of RAD[edit]

Currently this section says: "Rapid Application Development (RAD) is a term originally used for describing a software development process first developed and successfully deployed during the mid-1970s by D.Dinadasa at New York Telephone Co's Systems Development Center under the direction of Dan Gielan. Following a series of remarkably successful implementations of this process, Gielan lectured extensively in various forums on the methodology, practice, and benefits of this process.[citation needed]" Does anyone have a reference for this? So far all I can find is this link: Which confirms the info but there are no references on that page. I plan to remove this if no one can provide a good reference. --MadScientistX11 (talk) 23:18, 30 June 2014 (UTC)

Yes check.svg Done --MadScientistX11 (talk) 16:20, 1 July 2014 (UTC)

Relative Effectiveness[edit]

I plan to completely rework this section but I wanted to document some of the things wrong with the current text in case anyone wants to defend it. To begin with the first sentence: "The shift from traditional session-based client/server development to open sessionless and collaborative development like Web 2.0 has increased the need for faster iterations through the phases of the software development process." Gives the wrong idea. RAD in the generic non-Martin sense is not at all restricted to UI driven systems (not to mention RAD was around way before Web 1.0 let alone later versions). One of the first examples of RAD was Barry Boehm's work which was on real time systems to control satellites. And there are plenty of documented cases of using Agile for systems where the UI was not the main driver. Then consider this sentence: "This, ... has, for many developers, rekindled interest in finding a silver bullet RAD methodology." First of all saying "searching for a silver bullet solution" is very much a POV statement. No one who has read and understood the Brooks paper where he coined the term silver bullet would say "I'm looking for the silver bullet" the whole point was that there is no one single magic solution to software productivity. Then there is this: "Rapid Application Development (RAD) can be considered as a type of Agile technique or vice versa" Now if we mean RAD in the generic sense then yes I agree but if it means (as I think was the intention as written) the James Martin approach absolutely that is false, RAD is nothing like Agile. I think I've said enough, if anyone wants to defend this section as written please speak up. --MadScientistX11 (talk) 23:45, 30 June 2014 (UTC)

I've rewritten everything except the last three sections at this point. All three of them essentially seem like they could be merged into one section, pros and cons or costs and benefits, something like that. I want to read through what's there and do a bit more research before tackling them but right now my plan is to just merge those three sections. BTW, I disagree with the statement in one section that most big products at IBM and elsewhere are still developed using a waterfall with "some spirals". First of all if there are spirals at all it's not waterfall and second that reference is old and out of date. IMO the vast majority of products these days are developed using some kind of RAD (not the Martin method but some form of rapid or agile development) methodology with prototyping. I'll see what kind of refs I can find. --MadScientistX11 (talk) 16:26, 1 July 2014 (UTC)
Yes check.svg Done --MadScientistX11 (talk) 18:30, 1 July 2014 (UTC)