Codejig logo

Rapid application development (RAD)

logo

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?

  1. The time for the development of the application is reduced, and the progress can be measured.

  2. The coding process is faster due to the usage of modern rapid application development tools such as code generators and low-code platforms.

  3. Changes can easily be made due to the compartmentalization of system components.

  4. Quick and constant reviews and critiques from users ensure satisfaction of end users.

  5. Integration is simple because this it is done from the beginning of the project.

  6. This method achieves high productivity with smaller teams.

What are the disadvantages of rapid application development?

  1. A small team with lots of collaboration is required to succeed therefore this model is not very suitable for large teams.

  2. The team members and developers need to be highly skilled and be able to assume different roles.

  3. 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.

  4. 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.