Rapid Application Development vs.

Agile
Methodologies

1. Introduction

The rapid application development and agile methodologies were both created as
responses to the perceived limitations of structured traditional management
techniques like the waterfall model. But, rapid application development was the first
engineering methodology to identify the underlying differences between software
engineering and conventional engineering. With conventional engineering projects
like mechanical systems, huge physical plants or bridges, engineers cannot start
building them and then change their minds halfway through. In contrast, software
development projects are transient. So, engineers can change their minds if needed.
RAD and agile models exploit this by welcoming changes in requirements even late
into the development process.

2. Rapid Application Development

Although contrived back in the 1980s, the use of rapid application development
(RAD) is currently proliferating and used as an expediting methodology for digital
transformation in 2018 and beyond. During the 1970s, software engineering projects
followed the waterfall model, a traditional engineering process, which is similar to the
methodology applied to building bridges and huge physical plants. In this
methodology, software architects work together with the stakeholders who
requested for the software to draft functional requirements, then spend countless
hours interpreting them in specifications sheets. Development begins only after all
the specifications were completed. Then, after months or sometimes years of
development, the stakeholders and end users of the software get their first look at
the completed software product. If it failed to meet the expected results of the
stakeholders, the engineers would rewrite the existing source code to meet
expectations, which in turn increases the delivery time and costs. (Pike, 2018)

During the 1980s, software engineers Barry Boehm and James Martin realized the
inherent flaw in this approach, the waterfall methodology. From their perspective,
unlike inflexible resources like bridges, software was changeable and they advocated
that software development projects needed to exploit this attribute. Consequently,
the rapid application development methodology was introduced in 1991 by James
Martin.

2.1. Advantages of Rapid Application Development

The intrinsic nature of RAD permits adaptability to changing customer requirements
throughout the development cycle. Consequently, the following are the benefits for
using RAD:

1. Shorter delivery time and Lower cost: By consistently presenting working

pieces of the product to stakeholders during the prototyping phase, shown in
figure 1, it is highly probable that the final delivery of the product will be
acceptable to the stakeholders and end users on the first time delivery. Also,
since the engineering team starts creating working prototypes right after the
requirements phase, there is a regular delivery to show to the stakeholders
within a short time span. Consequently, this saves time and lowers the cost on
resources.
2. Higher Satisfaction: By having the customer always there at every step of the
process as prototypes are delivered frequently, the client becomes more
confident about the final delivery. Also, the development team is constantly
getting immediate feedback which allows them to quickly address any
changes that need to be made before the prototypes are added to the
completed product. As a result, both the client and the development team are
satisfied. (Pike, 2018)

2.2. Disadvantages of Rapid Application Development

While RAD facilitates a shorter delivery time and a higher satisfaction for both the
clients and the developers, RAD is not perfect and has its own drawbacks including:

1. Scale: While a small team of developers can readily adapt to changing

requirements from the client, it will be very challenging to keep a large,
distributed team on the same page since inter-communication between the
smaller teams will begin to slow down and disorganize the direction of the
project. (Idesis, 2017)
2. Commitment: The recurring cycle of prototypes in RAD demands developers
and clients to commit to regular feedback assessment and feedback meetings,
which may seem overwhelming.
3. Interface-focus: Since RAD is prototype intensive, clients may justify the
quality of the product by what they can interact with, and normally what they
interact with is a charade of the expected result. Therefore, there’s a risk that
some best practices are ignored by developers on the back-end to expedite
development of the front end. (Pike, 2018)

3. Agile Methodology
Created in February 2001 by 17 software developers, agile recognizes that software
projects are fundamentally unpredictable and that there are likely to be changes over
the course of the project. These changes, be it market changes or feature changes as
the product comes to life will need to be addressed. As shown in figure 2, agile
welcomes this volatility by breaking down projects into small chunks called sprints, to
facilitate prioritization and allowing engineers to add or drop features during the
project.

3.1. Advantages of Agile Methodology

Agile methods stress efficiency and practicality over heavy-weight process overhead
and documentation. Advantages of the agile methodology include:

1. Speed to market: Documentation in agile is short and to the point. This cuts
down the time spent on heavyweight documentation allowing agile teams to
a get working deliverable to the client in a short time.
2. Risk management: Incremental software delivery to the client helps identify
issues and feature deficits early in the process. Through feedbacks received
from the stakeholders and end users, project managers are quickly informed
about potential risks which can addressed earlier in the development process.
3. Customer satisfaction: Since customers are consistently involved throughout
the entire project, improvements can be made to the working software based
on customer feedback. Consequently, customers receive a high quality final
product guaranteeing the customer’s satisfaction as the entire software is
developed based on the requirements taken from customer.

3.2. Disadvantages of Agile Methodology

Though the agile model is revolutionary and offers a different approach to the
traditional waterfall model, there are various limitations which include:
 1. Lack of documentation: Although less documentation saves time in the
development process, this can be a big disadvantage for new developers
joining the team at the later stage since it will be difficult to understand the
actual method followed to develop the software.
2. Possible process derailment and time-wasting: The agile methodology
heavily depends on customer interaction. Therefore, it is probable that the
development process goes out of the track when the customer is not clear
about product features and requirements. As a result, a huge amount of time
and resources may be wasted in the process leading to an increase in
development cost and delivery time.

4. Conclusion

In conclusion, although RAD and the agile methodologies share similar values, with
regards to flexibility, shorter delivery time, and high customer interaction and
satisfaction, RAD is primarily focused on prototypes while agile is mostly focused on
breaking down the project into features which are then delivered in various sprints
over the development cycle. Based on the discussed advantages and disadvantages
of RAD and agile methodologies, RAD is mostly suitable for projects with preferably
six or fewer highly skilled developers, where prototypes are allowed within very tight
deadlines. On the other hand, the agile methodology is generally suitable for
projects with ideally twenty or less developers, where incremental feature delivery is
the main focus.

References

 Nick Pike. 2018. “Which do you need? Rapid application development vs

Agile” Retrieved from https://www.enterpriseinnovation.net/article/which-do-
you-need-rapid-application-development-vs-agile-977455002
 Wikipedians. 2013. “Modern Software Methodologies for Software
Engineering” Retrieved
from https://learn.umuc.edu/d2l/le/content/354997/viewContent/14199255/
View
 Stanley Idesis. 2017. “What Is Rapid Application Development?” Retrieved
from https://www.outsystems.com/blog/rapid-application-development.html
Agile is a set of principles about software development. It focuses mostly on breaking
down the project into features, each built in a different sprint (usually focusing on the
most difficult one first). In some ways, it still uses the basic waterfall concepts, but
creates dozens of iterations to get more feedback and testing done as each feature is
finished.

RAD is more focused on prototypes. In RAD, the primary focus is to get something
usable in front of the client as quickly as possible to get feedback. In the RAD model,
you may show the client something still in the development phase, whereas Agile will
usually wait until a specific feature is designed and built before showing it.

Also, RAD tends to be less focused on the UI/UX in favor of functionality, while Agile is
more likely to consider the design as an essential part of the product.