This is the
talk page for discussing improvements to the
Rapid application development article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
Isn't there also an Interface Builder for Mac OS X?
== == == Advantages and disadvantages == == ==
jh
|- through the involvement of the user in the analylsis and design stages |}.
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)
An what about "Pro: Decreased end-user functionality" ? I'd say that's a definate CON .. not a pro —Preceding unsigned comment added by 212.178.96.70 ( talk) 06:11, 13 September 2007 (UTC)
I don't understand this Con. _What data?
Modern RAD tools now has the richest features and the most scalable.
RicoWiki 01:13, 26 June 2006 (UTC)
rap model is
I think this article isn't really a stub anymore?
Jaapvstr 10:11, 13 September 2006 (UTC)
What was the first langauge to employ RAD techniques? Mathmo Talk 23:40, 8 May 2007 (UTC)
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). 58.105.242.113 ( talk) 04:03, 22 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). 58.105.242.113 ( talk) 04:54, 17 June 2009 (UTC)
On 5 February 2008 Gingerbits ( talk) added this Pro:
and these commentaries on the following Cons:
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 ( talk • contribs) 15:14, 9 March 2009 (UTC)
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)
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)
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)
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 83.89.33.37 ( talk) 01:23, 9 May 2012 (UTC)
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)
What does RAD Jepoy mean ? Kesstrelle ( talk) 19:21, 29 November 2013 (UTC)
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)
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)
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: http://helpdesksurvival.com/rapid-application-development-history.html 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)
Remove it already. We can't google anything on 'Dan Gielan' — Preceding unsigned comment added by 36.84.235.233 ( talk) 06:43, 4 July 2019 (UTC)
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)
Kku you recently reverted my revert of your unsourced change to this page. The proper response in such a situation is to take to the talk page and discuss it, not to just undo the revert. I think adding a section on RAD Frameworks is a good idea but to do that you need wp:sources You have none. The Wikipedia policy here is unambiguous and I'm deleting your unsourced addition. Also, assuming at some point you have good references, I think the new section needs some text not just a list. I think that’s always a good idea but on this page its especially important. Something we had to grapple with is that RAD means very different things to different IT audiences. The distinction between the James Martin definition and the definition that comes out of the iterative development approaches that led to Agile methods. If we add specific frameworks we need to make clear which approach the framework supports. If you disagree please discuss here, don't start wp:edit warring. Thanks. -- MadScientistX11 ( talk) 21:06, 19 May 2017 (UTC)
I reverted some changes to the introduction by Volunteer1234. First of all the revised text was ungrammatical. The new intro sentence was "Rapid application development (RAD) is an approach to software development put less emphasis on planning and more emphasis on process. RAD includes..." Besides being ungrammatical it's not clear what that sentence really means. I agree that RAD puts less emphasis on planning but how does it "put more emphasis on process"? If anything, many RAD methodologies such as Agile put very little emphasis on specific life-cycle stages, phases, etc. Also, a key point in the article is that RAD is both a generic term and a term for James Martin's methodology. The new version of the intro reads as if Martin's term and RAD are the same thing which they absolutely are not. People like Barry Boehm were using the term RAD years before Martin developed his methodology. -- MadScientistX11 ( talk) 00:15, 25 July 2017 (UTC)
I just reverted a change that added this sentence: "In simple words RAD is a special software which aims at building programs vastly through the use of tools and wizards." RAD is a software process not a software tool. It's an approach to building software. Yes, there are various tools and technologies (GUI builders, OO IDE's, rule based systems) that are commonly used for RAD but the initial RAD: Barry Boehm's spiral model was done using very traditional software that didn't even HAVE a GUI, Boehm's spiral model was first used to develop the software that goes into sattelites. -- MadScientistX11 ( talk) 18:11, 7 August 2017 (UTC)
An unidentified user (different IP addresses), has twice introduced Sir Drake as a close associate of Boehm and an influence on the early stages of RAD. However, no references have been cited. The only connection between those two names I can find on Google (admittedly not the fount of all knowledge) is that in 1883 a sculptor called Joseph Edgar Boehm created a statue of Sir Francis Drake in the town centre of Tavistock, Devon, UK. The second change has been reverted with a request to discuss the changes here and to provide cited references. Davidjcmorris Talk 23:39, 29 January 2018 (UTC)
This is the
talk page for discussing improvements to the
Rapid application development article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
Isn't there also an Interface Builder for Mac OS X?
== == == Advantages and disadvantages == == ==
jh
|- through the involvement of the user in the analylsis and design stages |}.
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)
An what about "Pro: Decreased end-user functionality" ? I'd say that's a definate CON .. not a pro —Preceding unsigned comment added by 212.178.96.70 ( talk) 06:11, 13 September 2007 (UTC)
I don't understand this Con. _What data?
Modern RAD tools now has the richest features and the most scalable.
RicoWiki 01:13, 26 June 2006 (UTC)
rap model is
I think this article isn't really a stub anymore?
Jaapvstr 10:11, 13 September 2006 (UTC)
What was the first langauge to employ RAD techniques? Mathmo Talk 23:40, 8 May 2007 (UTC)
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). 58.105.242.113 ( talk) 04:03, 22 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). 58.105.242.113 ( talk) 04:54, 17 June 2009 (UTC)
On 5 February 2008 Gingerbits ( talk) added this Pro:
and these commentaries on the following Cons:
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 ( talk • contribs) 15:14, 9 March 2009 (UTC)
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)
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)
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)
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 83.89.33.37 ( talk) 01:23, 9 May 2012 (UTC)
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)
What does RAD Jepoy mean ? Kesstrelle ( talk) 19:21, 29 November 2013 (UTC)
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)
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)
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: http://helpdesksurvival.com/rapid-application-development-history.html 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)
Remove it already. We can't google anything on 'Dan Gielan' — Preceding unsigned comment added by 36.84.235.233 ( talk) 06:43, 4 July 2019 (UTC)
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)
Kku you recently reverted my revert of your unsourced change to this page. The proper response in such a situation is to take to the talk page and discuss it, not to just undo the revert. I think adding a section on RAD Frameworks is a good idea but to do that you need wp:sources You have none. The Wikipedia policy here is unambiguous and I'm deleting your unsourced addition. Also, assuming at some point you have good references, I think the new section needs some text not just a list. I think that’s always a good idea but on this page its especially important. Something we had to grapple with is that RAD means very different things to different IT audiences. The distinction between the James Martin definition and the definition that comes out of the iterative development approaches that led to Agile methods. If we add specific frameworks we need to make clear which approach the framework supports. If you disagree please discuss here, don't start wp:edit warring. Thanks. -- MadScientistX11 ( talk) 21:06, 19 May 2017 (UTC)
I reverted some changes to the introduction by Volunteer1234. First of all the revised text was ungrammatical. The new intro sentence was "Rapid application development (RAD) is an approach to software development put less emphasis on planning and more emphasis on process. RAD includes..." Besides being ungrammatical it's not clear what that sentence really means. I agree that RAD puts less emphasis on planning but how does it "put more emphasis on process"? If anything, many RAD methodologies such as Agile put very little emphasis on specific life-cycle stages, phases, etc. Also, a key point in the article is that RAD is both a generic term and a term for James Martin's methodology. The new version of the intro reads as if Martin's term and RAD are the same thing which they absolutely are not. People like Barry Boehm were using the term RAD years before Martin developed his methodology. -- MadScientistX11 ( talk) 00:15, 25 July 2017 (UTC)
I just reverted a change that added this sentence: "In simple words RAD is a special software which aims at building programs vastly through the use of tools and wizards." RAD is a software process not a software tool. It's an approach to building software. Yes, there are various tools and technologies (GUI builders, OO IDE's, rule based systems) that are commonly used for RAD but the initial RAD: Barry Boehm's spiral model was done using very traditional software that didn't even HAVE a GUI, Boehm's spiral model was first used to develop the software that goes into sattelites. -- MadScientistX11 ( talk) 18:11, 7 August 2017 (UTC)
An unidentified user (different IP addresses), has twice introduced Sir Drake as a close associate of Boehm and an influence on the early stages of RAD. However, no references have been cited. The only connection between those two names I can find on Google (admittedly not the fount of all knowledge) is that in 1883 a sculptor called Joseph Edgar Boehm created a statue of Sir Francis Drake in the town centre of Tavistock, Devon, UK. The second change has been reverted with a request to discuss the changes here and to provide cited references. Davidjcmorris Talk 23:39, 29 January 2018 (UTC)