Rapid Application Development - Criticism

Criticism

Since rapid application development is an iterative and incremental process, it can lead to a succession of prototypes that never culminate in a satisfactory production application. Such failures may be avoided if the application development tools are robust, flexible, and put to proper use. This is addressed in methods such as the 2080 Development method or other post-agile variants.

Furthermore, there is a phenomenon behind a failed succession of unsatisfactory prototypes: End-users intuitively and primarily look to the Graphical User Interface (GUI) as a first measure of software qualities. The faster they "see" something working, the more "rapid" they perceive the development cycle to be. This is because the GUI has a strong natural directly viewable presence, while other problem domain code must be deduced or inferred, going largely unnoticed.

As programmers are generally software end-users first and programmers later, this natural gravitation towards "seeing" is engrained from the beginning (e.g. "Hello World" is not about the data or business domain, but is about "seeing" something on a screen). Programmers without clear training towards understanding this deceptive quality of software also tend to gravitate their measurement of "rapid" in RAD by how quickly the GUI progresses. The tendency is further strengthened by the fact that end-users hold the financial reward programmers seek, leading them to ignorantly cater to the measurement mind-set of the end-user rather than a suitable and more realistic alternative.

Consequently, many software development tools strongly and primarily focus on the application GUI as well. This tendency to measure "rapid" by means of the GUI is strengthened further by programmers who (in turn) become RAD tool producers. They also have a strong financial interest and cater to the software development community GUI-centric model. Finally, an anecdotal review of RAD tools reveals the strong GUI focus, where "Hello World" and other GUI-centric examples abound and a dearth of data or business problem domain examples exist.

Ultimately, the triad of players (e.g. end-users, programmers, tool-developers), each with a strong and misplaced focus on the GUI aspects of software applications leads to a cultural underemphasis of the bulk of what the software text is actually about: The business and data problem domains. Furthermore, the culture of RAD (and indeed of software in general), with the central GUI emphasis, presents a multifaceted problem for engineers who recognize the problem and seek to overcome and engender an opposite environment (end-users, developers and tools).

First, there is the lack of rapid application development tools that emphasize the appropriate problem domain. Next, appropriately trained engineers have the task of training and educating end-users to see the counter-intuitive data and business code as the appropriate measure of how well or rapidly a software product is being developed. Finally, there is a lack of project engineers who understand the misplaced problem domain and are trainable and capable to the task of reorienting themselves to the counter-intuitive viewpoint.