A Guide to Understanding Rapid Application Development (RAD) in 2017

As the desire to build custom software solutions continues to grow for organizations of all shapes and sizes, the endeavour to make the development and testing process faster becomes a never-ending challenge.

Businesses want high-functioning, beautiful looking, and scalable software without waiting for months and months of development. But most are not 100% confident in the fast software development solutions available.

You’re probably well aware of the buzz around Rapid Application Development (RAD) and low-code development platforms - they are hardly groundbreaking news.

The original methodology of RAD was developed way back in 1991 and has since been overtaken by what is referred to as Agile software development. But the powerful low-code frameworks and platforms becoming available to developers today, can make applications faster than ever before, and they are also considered RAD technologies.

RAD technology can help projects stay on-budget, and provide faster delivery. So given the fact that $122 million is wasted out of every $1 billion spent on custom software projects, this makes this approach to development attractive to many large organizations that need custom software tools.

But just like everything else, RAD has its disadvantages. In this article, we’ll take a closer look at Rapid Application Development – both the good and the bad – and help you gain a more comprehensive understanding of this approach to development. Let’s dive in.

What is Rapid Application Development (RAD)?

The term Rapid Application Development (RAD) can refer to both a methodology of software development, as well as a technology.

As a software development methodology, RAD came to the forefront in 1991 to deal with some of the issues found with larger-scale, “engineering-based” development systems such as Waterfall.

Instead of focusing on gathering customer requirements, pre-planning features and software, and creating an extensive roadmap for software development, Rapid Application Development favors rapid prototyping of actual products.

These “working models” are functionally equivalent to the actual end product. Using customer feedback, workshopping, and QA testing, these prototypes are quickly developed, changed, refined, and shaped into an end component of the product.

Using the RAD methodology, each functional module of a product is developed in parallel as a prototype, and built to be easily integrated. This allows for faster product delivery – and because there is no in-depth pre-planning required, it’s easier to make changes during the development process, increasing business agility.

Generally, each component or prototype has its own small team, including IT resources, developers, and domain experts. Using a small-scale model of change, each prototype is developed incrementally, and tested after each iteration has been completed.

RAD is considered one of the earlier adaptations of what is now referred to as Agile software development, with the key difference being the flexibility and speed of changes associated with a more Agile approach.

RAD technologies such as Rational Rose, Ruby on Rails and the OutSystems low-code platform, apply some of the thought processes associated with the original RAD methodology, to a modern way of fast development. These technologies enable Agile development teams to be truly agile by avoiding the need to “re-code” every component of a project.

Why did the RAD methodology need to be updated?

Even though the RAD methodology brought a unique way of thinking to software development in the 1990’s and helped accelerate the delivery of many software projects, it lacked the flexibility to survive in a world craving custom solutions in short timeframes.

Let’s take a closer look at some of the key advantages of the RAD methodology that have been brought forward with Agile, as well as examining the disadvantages that potentially lead to it’s overtaking.

Advantages of the RAD methodology

• Changes can be easily incorporated into the end product – Because each iteration of a prototype is essentially a functional product, and each component is separated, it’s easy to make basic scope changes, compared to changes made in other methodologies such as the conventional Waterfall Model.
• Progress is easy to measure – Each prototype is, essentially, a functioning version of the end product, which means that it’s easy to see how work is progressing.
• Iteration time is extremely short – Because of the focus on prototyping vs. planning, each individual iteration of a product can be developed much more quickly.
• Smaller development teams – Using advanced low-code tools and the RAD methodology, the need for extra project managers and developers is reduced, leading to lower costs, and smaller, more manageable teams.
• Quick initial reviews and customer feedback – RAD allows your team to gather real customer feedback very quickly, and adjust your product accordingly if your client is not satisfied.
• Few integration issues – Each module of a RAD-developed product is built to integrate perfectly with the others, and the rapid prototyping model allows potential integration issues to be dealt with before they become a problem.
• Shorter overall development time – Long development times (anywhere from 6 months to over a year) are what hold many businesses back from working with custom software shops. But with RAD, fully-featured products can be made often within as little as 60 days.

While some projects are a perfect fit for the RAD methodology, there are some disadvantages that must be considered too.

Disadvantages of the RAD methodology

• Higher management complexity – Traditional SDLC methods, like Waterfall, provide management with a simple, milestone-based method of measuring progress. However, RAD does not – instead, management must develop a deeper understanding of each prototype in order to measure progress, which can make things quite difficult for managers who are not used to doing so.
• Only suitable for scalable, component-based systems – RAD is best used for large systems with multiple components. This is because, using RAD, many pre-developed components will be used, and it’s not cost-effective to create a single component or piece of software for a smaller company.
• Require heavy user involvement throughout the entire software lifecycle – Because a new prototype may be released weekly, your team will have to cooperate closely with end-users throughout the entire process, in order to accurately test your product.
• Need accurate business requirements up front – Highly experienced team members are required to ensure that you accurately capture business requirements of your customer before beginning development. If the initial requirements and design of your product are wrong, you risk serious scheduling and budgetary setbacks.
• Not suitable for projects with high technical risk – Since much of the code in a RAD model is not custom-made, RAD is a poor choice for any software application that is seriously technically challenging.
• More potential defects – Though they’re usually caught quickly, most RAD models lead to more bugs, defects, and coding errors, due to the rapidity of development and the use of third-party tools and disparate modules.

While all of these disadvantages can be mitigated by choosing a great team, working with the right clients, and having the right expectations, they have contributed to the need for a more flexible approach to fast development, such as Agile.

What is the process for using RAD?

Even though RAD has needed to evolve, it is interesting to take a look at the process of this methodology and how it has shaped the current landscape of low-code software development.

The process for using RAD is quite simple, and can be broken down into 5 essential steps.

Step 1: Business Modeling

In the initial business modeling phase, the basics about customer requirements, functionality, and data flow are gathered. These business requirements are collected, and used to inform the next step of the process.

Step 2 - Data Modeling

The information collected in the “business modeling” phase of development is refined into a set of “data points” that are significant to the business.

Step 3 - Process Modeling

The “data points” set forth in the data modeling phase are transformed into actual data-based business processes. This is when the basics about information transfer, application features, and business processes are set forth.

Step 4 - Application Generation

Using automated low-code tools and platforms, previous software modules, and custom-made code when necessary, an application is quickly developed that includes the features set forth in the “process modeling” phase.

Step 5 - Testing/Turnover

Prototypes are individually tested during each and every iteration, both by developers and by end-users. This allows for a very fast turnover cycle, and allows developers to quickly create a functional, intuitive product.

Though you could write a book about the subject, (and we’d recommend Rapid Development: Taming Wild Software Schedules by Steve McConnell if you’re interested) these 5 basic steps will hold true for every project that’s developed using the RAD methodology.

Is RAD still relevant?

RAD is still relevant because businesses are moving as fast as they ever been. So as long as the need for speed exists, the need for RAD and Agile will continue to exist as well.

Entire industries are being disrupted by new products and new technology designed specifically to make things faster than what is available in the current market. You see this with platforms such as AirBnb, Uber, and others.

Technology is evolving and low-code is just one example of that.

So even though RAD as a methodology is a little outdated, there are fundamental components of this way of thinking that have shaped the progression of Agile software development, and low-code technology.

As time goes on, we’re likely to see more and more companies using low-code technology to develop applications, especially as more small businesses begin to take advantage of custom-built internal and external applications. And even though RAD isn’t a perfect methodology, it’s very much evident in a modern approach to fast software development – and for smaller development teams, the benefits are hard to ignore.

I'm lucky enough to work for OutSystems, one of the leading providers of low-code development tools. Our low-code framework can be used to build mobile applications, web applications and portals, and much more.

Find out more here.