Increasing interest is being taken in the employ of quick application development. Why is that, and are there any dangers related with the RAD approach?
RAD has come to prominence due to the increasing pace of change into all organisations. The argument is about that, against this a background, the conservative, linear approaches that are represented by the waterfall lifecycle, which do not make results rapidly adequate. Frequently, it is more significant to get several sort of solution rapidly than the best solution into a couple of years. Moreover, the advocates of RAD, for illustration the DSDM Consortium, contend which, due to the close working relationship among users and developers which is inherent into the RAD approach, the users are more probable to acquire a system which meets their real requirements than with a more conventional approach. Certainly, in recent years, RAD’s proponents have been stressing fitness to function over speed of development.
The major dangers related with RAD are to do along with its very speed within that this leaves for a moment for reflection and, when not managed tightly, less yet for documentation. Several critics have explained RAD as a ‘licence to hack’. The real problems along with poorly documented systems come afterwards into their lifecycle, while maintenance becomes complicated and unpredictable, as the support engineers do not have sufficient information on why and how the system has been made as this is. A further potential problem is which the part of the system selected as a starting point due to perceived business requirements – may not, actually, turn out to be rather so central and the completed system may be ‘skewed’ as a result.