Rapid
application development (RAD)
Syxtus
June 6th, 2019 • Software development
Morning in Casablanca
It
was a sunny and a very fine spring morning with the smell of Sampaguita
in the air. By some curious chance, while waiting for my bus to
arrive at the bus stop, I couldn’t help but eavesdrop on a
conversation between 2 students next to me. From the bits and pieces
I could gather, they were discussing the lecture on programming
methodologies they had the previous day. They were arguing that rapid
application development is not rapid at all.
As
a young geek, with an omniscient mind, I was so eager to overwhelm
them with my knowledge. So, I jumped into the conversation and
introduced myself as the guy who is about to clear all the doubts
they had on rapid application development.
The
first question one of the guys asked was, “How would I define Rapid
application development?” Honestly, I was expecting a more
complex question about RAD. And by the way, his name was Kelvin and
his friend’s name was Taras.
To
answer Kelvin’s question, I had to take them back to explain how
computer hardware and software development has evolved over the
years.
Software development - The Genesis
In
the beginning, there was nothing. Absolutely nothing. Darkness. No
social networks, no smart phones, no blogs, total darkness. Some say
that TV and cinema existed before computer was created but I do not
buy that. With the creation of the first computer, came the light
and, eventually software got separated from hardware. During those dark ages of gender inequality,
men mostly dealt with hardware engineering since hardware was very
expensive, broke often and it was prestigious and lucrative to repair
it. Women and children tended to software. As time passed, the
hardware became less and less expensive. At the same time a lot of
software was being created (you see, children like to play a lot). The
software became more complex and expensive to maintain and, in a rather
short time, the cost of developing new software became higher than
the cost of hardware that run it. The turning point was the introduction of
personal computers some around 1985 A.D. - well, about 15 years
before I was born.
Naturally,
men turned their attention to software development and tried to cut
costs by improving organization and introducing some planning. Well,
not some but a lot of it – every project had to be thought out in
details before it started. This approach became known as the Waterfall
method.
Kelvin
interrupted my explanation to say that he is well familiar with the
concept of the waterfall and that he fell into water more than once.
This was actually a main idea behind waterfall method – plan
everything in detail, then make one big jump, fall and see what
happens. Sometimes projects landed well, but other times it never came
out to the surface. Sometimes it emerged a few miles down the stream
where no one expected it – and resulting software worked according
to the plan but most often contrary to the expectations of end-users.
This was clearly not very pleasant to those who wanted more reliable
outcomes and some started to doubt if so much planning is necessary.
The process was also quite long, preparations and planning took a lot
of time, and spectators (mostly CEOs and customers who financed the
projects) who watched the falls and made bets on the outcome were
not happy with the long waiting times. They kept asking for low costs,
fast development, and high-quality results – a combination which
most software development processes have found difficult to deliver.
Then I asked Kelvin, “who will be in favor of getting a high-quality
application in a short period of time at a low cost?” His response
was pretty obvious, everyone.
Rapid Application Development methodology
Rapid
application development (RAD) methodology
has been a response to this dream and to the shortcomings of the Waterfall
model. It came close to finding the balance between speed, cost, and
quality of software development. The basic idea is – let’s make
less planning, more prototyping, and involve end-users earlier. This
idea got into people minds in the beginning of the 90s (about 10
years before I was born)
and a number of books were written and conferences held around it. Then new tools like Borland Delphi introduced features like visual UI
editors which made prototyping and collaboration with end users
easier. Projects started to be delivered much faster and according to
end user wishes but quality varied. Some folks, following natural
inclination, decided to abandon the planning at all, and that led to
disastrous outcomes on large complex projects.
As time passed, the concept became a bit blurred and the rapid
application development definition a bit vague.
RAD methodology has many
uses and that is why many people started to use the term in a way
that suits them. Some meant it as a methodology, some as a set of UI
tools and some just used the word on every occasion when they needed
an app to be developed fast.
“That
is all very good, “ finally Taras who’s been listening silently
all this time entered into the conversation - “but that is history.
What is rapid application development now?”.
What is Rapid Application Development now
Nowadays,
I would define RAD as an integrated set of guidelines, techniques, and
tools that eases and enables the development of software in a short
period of time. The time used for development is called the timebox.
The customer is actively involved in the application development
process by sending feedbacks. In this method,
the customer gets to see the product at almost all the stages of
development, meaning bits and pieces or chunks of the application are
delivered in order of business importance. It mandates intensive collaboration between developers and customers to
reach the final product.
The tools and techniques of rapid
application development enable fast production but require the developers to
keep the balance between flexibility and discipline. The RAD method
relies heavily on the ability and skills of the developers and the
feedback from the customers to function properly.
I
went on to explain the steps involved in rapid application
development:
Even
though there are many variations to the RAD model, the entire process
in the rapid construction of the software is more or less the same.
The process can be broken down into the following steps:
1. Define the desired product
In
the initial planning phase the project scope needs to be defined
along with the initial process/data/risk analysis. The specification
is developed but it is neither complete nor a strict one. Within this
stage, a timebox is chosen, which is a fixed period used to build a
chunk of the application. The team need to perform business area
analysis to split the project into subsets that would potentially fit
into timeboxes. The most compelling needs and requirements should go
into the first chunk.
2. Prototyping,
architectural design, modeling, coding, and testing
All
of these processes occur iteratively within the chosen timebox. Timeboxing
enables the developers to reduce the scale of the product delivery
and focus on the significance of the project. Multiple timeboxes can
be going on at the same time or in sequences.
During
this step, the development team and the customers need to work
together to arrive at a common goal. Prototypes are created and
presented to the customers. Nothing at this stage is permanent, as
features can be added and deleted based on various needs. The first
prototype presented to the consumer sets the pace and the
relationship between the development team and the customer. Chunks of
the application are also developed and prioritized based on the needs
of the business.
Rapid
application development tools are an important part of the
construction process. These tools are used to construct the GUI
interface, capture the application model, record the development process, generate test scripts, build code, and assist in the
management of software configuration.
Testing
helps the development team to identify and fix bugs, thereby giving
the application more quality. The testing is done often and bugs are
eliminated as found .
Note
that the prototyping, architectural design, modeling, construction,
and testing are repeated continuously until the timebox objectives
are met.
3. Receive
feedback
In
this step, customers give critiques and review the chunk or
version of the application that is presented to them. They may also
suggest what features they want to see added or removed from the
version presented to them. This process goes on until the final product is ready.
4. Finalize
the application
Once
all the testing has been done, the development team and the customer
sit together again for the last time to go through all the features
of the application before the final product is handed over.
I
took a little pause for them to digest all the information and for me
to restore breath. Then Taras asked, “When
will it be suitable to use the rapid application development model?”. Well, it depends on lots of factors like the amount of resources
available, the budget, time, and type of project. So, I went on to
give them the advantages and disadvantages of RAD
What are the advantages of rapid application
development?
The
time for the development of the application is reduced, and the
progress can be measured.
The
coding process is faster due to the usage of
modern rapid
application development tools
such as code generators and
low-code
platforms.
Changes
can easily be made due to the compartmentalization of system
components.
Quick
and constant reviews and critiques from users ensure satisfaction
of end users.
Integration
is simple because this it is done from the beginning of
the project.
This
method achieves high productivity with smaller teams.
What are the disadvantages of rapid application
development?
A small team with lots of collaboration is required to succeed therefore this model is not very
suitable for large teams.
The
team members and developers need to be highly skilled and be able to
assume different roles.
End-usersneed to be moved throughout the process and they are often busy with
their core business and unable to devote enough time to the project.
RAD works
well with smaller projects and might become a mess when dealing with really
large and complex applications.
Will
the RAD approach stand the test of time? With the coming of cloud
services and smart phones, the demand for apps has exponentially
increased. The competition in today's market has
become tense and there is no time to waste. I don’t think that will change
any time soon. If anything, the demand for more apps will increase
and the rapid application development model will be more
useful in this scenario.
I was so engaged in the
discussion that I did not notice the amount of time that had gone by. I
had missed my bus and probably the guys had missed theirs too. They
decided to complete the journey on foot and bid me farewell with
smiles on their faces while I stood at the bus stop waiting for the
next bus, a bit hungry and dreaming about the next big thing.