Editing Rapid application development (section)

== Disadvantages ==
The purported disadvantages of RAD include:
* The risk of a new approach. For most IT shops RAD was a new approach that required experienced professionals to rethink the way they worked. Humans are virtually always averse to change and any project undertaken with new tools or methods will be more likely to fail the first time simply due to the requirement for the team to learn. 
*Lack of emphasis on [[Non-functional requirement]]s, which are often not visible to the end user in normal operation. 
* Requires time of scarce resources. One thing virtually all approaches to RAD have in common is that there is much more interaction throughout the entire life-cycle between users and developers. In the waterfall model, users would define requirements and then mostly go away as developers created the system. In RAD users are involved from the beginning and through virtually the entire project. This requires that the business is willing to invest the time of application domain experts. The paradox is that the better the expert, the more they are familiar with their domain, the more they are required to actually run the business and it may be difficult to convince their supervisors to invest their time. Without such commitments RAD projects will not succeed.
* Less control. One of the advantages of RAD is that it provides a flexible adaptable process. The ideal is to be able to adapt quickly to both problems and opportunities. There is an inevitable trade-off between flexibility and control, more of one means less of the other. If a project (e.g.  [[Life-critical system|life-critical software]]) values control more than agility RAD is not appropriate. 
* Poor design. The focus on prototypes can be taken too far in some cases resulting in a "hack and test" methodology where developers are constantly making minor changes to individual components and ignoring system architecture issues that could result in a better overall design. This can especially be an issue for methodologies such as Martin's that focus so heavily on the user interface of the system.<ref name="PratImp">{{cite conference
| citeseerx = 10.1.1.100.645
| title = Practical Implications of Rapid Development Methodologies
| first1 = Aurona
| last1 = Gerber
| first2 = Alta
| last2 = Van Der Merwe
| first3 = Ronell
| last3 = Alberts
| date = 16–18 November 2007
| conference = Computer Science and IT Education Conference
| conference-url = http://csited.org/
| book-title = Proceedings of the Computer Science and Information technology Education Conference, CSITEd-2007
| location = Mauritius
| pages = 233–245
| isbn = 978-99903-87-47-6
}}</ref>
* Lack of scalability. RAD typically focuses on small to medium-sized project teams. The other issues cited above (less design and control) present special challenges when using a RAD approach for very large scale systems.<ref name="SpecsOnLine">{{cite book
 |last = Andrew Begel
 |first = Nachiappan Nagappan
 |title = First International Symposium on Empirical Software Engineering and Measurement (ESEM 2007)
 |chapter = Usage and Perceptions of Agile Software Development in an Industrial Context: An Exploratory Study
 |chapter-url=http://research.microsoft.com/pubs/56015/AgileDevatMS-ESEM07.pdf
 |date=September 2007
 |pages = 255–264
 |doi = 10.1109/esem.2007.12
|isbn = 978-0-7695-2886-1
 |s2cid = 1941370
 }}</ref><ref name="RAD2">{{cite book|doi=10.1109/icse.2003.1201238|chapter=Assessing test-driven development at IBM|title=25th International Conference on Software Engineering, 2003. Proceedings|pages=564–569|year=2003|last1=Maximilien|first1=E.M.|last2=Williams|first2=L.|isbn=0-7695-1877-X|s2cid=16919353}}</ref><ref name="RAD3">{{cite book|doi=10.1007/978-1-4302-0810-5|title=Extreme Programming Refactored: The Case Against XP|year=2003|last1=Stephens|first1=Matt|last2=Rosenberg|first2=Doug|isbn=978-1-59059-096-6|s2cid=29042153|url-access=registration|url=https://archive.org/details/extremeprogrammi00matt}}</ref>