Talk:Rapid application development

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

Rapid application

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

jh

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 212.178.96.70 (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 131.128.81.206 (talk) 15:59, 16 January 2008 (UTC)

RAD is not scalable and reduced features...NOT TRUE ANYMORE!

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

RicoWiki 01:13, 26 June 2006 (UTC)

Stub status

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?

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

What the hell is it?

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)

You open up a number of interesting topics. Let's begin with a couple of definitions:

Developer

A professional who can analyse a problem and design a solution as well as programming software

Analyst

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).58.105.242.113 (talk) 04:54, 17 June 2009 (UTC)

More Pro and Con commentary

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)

Methodology?

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

"Relative effectiveness" table

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?

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.