Waterfall vs. RAD – Which One Is Best For You?

Neil Miller

November 8th, 2018 RAD  

As software continues to develop at an overwhelming speed, it’s important to back it up, and look at how it’s made. Two of the most popular development methods are waterfall and RAD (Rapid Application Development). Here’s a good comparison of the two, along with some extra notes about how Agile development principles compare.

waterfall vs rad vs agile

What Is the Waterfall Model?

The waterfall model of development was established many decades ago as a definitive way to approach engineering projects. Its name comes from the fact that progress flows down sequential steps.

The engineering team will first meet with the client to discern all of the requirements. Then the engineers design a solution to meet the requirements. Next, they build the solution. Once it is ready, they take the solution back to the client for testing, and after fixing all the bugs, they deploy it and carry out scheduled maintenance.

What Is the RAD Model?

Rapid application development came as a response to problems when applying the waterfall model to software development. Software is uniquely different than other types of engineering because changes can be made almost immediately and even very late in the development process.

RAD is based on four core concepts:

  • Reusable code in an accessible repository
  • Quick prototyping
  • Constant client feedback
  • Building usable software as quickly as possible

The client and developer work together to create an end product that functions exactly as the client wants.

Waterfall vs. RAD: Which Is Better?

Although RAD is a unique model for software development, that doesn’t mean it’s always better. In fact, many developers still prefer the waterfall model. Here are several different factors that can help you choose which model is best for you.

Waterfall RAD
Time Sticks to a planned schedule, needs to start back at the beginning if significant changes emerge Open-ended, the project is done when the client is happy
Ideal Size of the Project Very small and very large projects Small and medium-sized projects
Developer Team Size Can be small to large Needs to be small
Developer Experience Level Can be junior to senior if the specs are clear Multi-talented, very experienced and flexible
Ideal Project Type On-premise, desktop applications Web-based, mobile apps
Ideal Client Extremely hands-off, knows exactly what he/she wants from the beginning Good communicator, open to suggestions, has the big picture, available
Worst client Changes mind frequently, wants to be involved all the time, scope creep Inaccessible, indecisive, uninterested
Risk Risk assessed at the beginning is accounted for, but not in the middle Respond and prepare for risks continuously
Approach to change Change is extremely negative Change is welcome
Best time for changes At the very beginning Anytime
Project Management Style Stick to the original plans and dates Very adaptive, more like driving an elephant
Use of new technologies No changes after specs are set New changes can be brought in anytime
Feature Management Every feature in the spec is built Only features that prove to be useful are built
Updates and Versions Planned and methodical Ad-hoc and quick
Costs Fixed costs, assuming no changes Variable, depending on the number of iterations
Prototype Delivered after the entire app is fully functional Working model delivered as soon as possible

What About RAD Vs. Agile? Are They the Same Thing?

When you look at RAD vs. Agile, they are very similar concepts. Both are reactions to the standard waterfall method. The differences between RAD and Agile are still emerging, as they aren’t usually seen as conflicting. However, there are some key distinctions you can make.

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.

Which One Is Right for You?

If you are considering waterfall vs. RAD or even RAD vs. Agile, the key questions you should ask have to do with the nature of the project and what kind of developers you have.

As clients, project leads, and developers become more skilled, there may be less of a need to follow the typical waterfall methodology. You can move to a more adaptive and faster means of development. But if your team is fairly inexperienced, relying on a traditional development model may be better in the beginning.

KiSSFLOW is an example of a business process application platform that works best with RAD principles. Users can create their own apps extremely fast and can make changes instantly. Try it today with a free trial and see just how fast process app development can be!