Traditional SDLC vs RAD
Building software isn’t like other projects. It never will be. Requirements can change on a dime, so development teams must be ready to adapt. Today we’re looking at one solution, as we compare traditional SDLC vs RAD.
The truth is that there’s no single right answer to managing software projects.
Indeed, different kinds of applications and teams will necessitate different approaches. So, the question isn’t so much if you should use different approaches, as when you should use them.
Today, we’re diving deep into everything you need to know.
We’ll take a look at the theory behind both approaches, including their key principles and rationale, before diving into the more concrete stuff. Along the way, we’ll cover the specific technical, operational, and resourcing considerations you’ll need to make.
But first, let’s start with the basics.
Traditional SDLC vs RAD: Definitions
Obviously, we need to clarify what it is we mean by SDLC vs RAD. So, let’s check out some definitions.
SDLC stands for software development life cycle. As a generic term, this can be any process that software projects follow from ideation to deployment. Traditional SDLC is something more specific, sometimes referred to as the waterfall model.
So what does this mean?
The term waterfall comes from the fact that traditional SDLC projects follow a fixed sequence of phases. Each of these must be completed before the next can begin. Once a phase is finished, projects rarely go backward.
Normally, this means a variation on the following structure:
- Requirements gathering.
- Systems design.
- Implementation.
- Testing.
- Deployment.
RAD, or rapid application development, is similar in terms of substance but differs in terms of how projects move through their various phases.
Instead of treating these as a fixed sequence, there’s more emphasis on iterative builds, continuous feedback, and evolving requirements. The goal here is to build tools faster, while better meeting users’ real-life expectations.
Check out our ultimate guide to rapid application development for more information.
(App Inventiv )
Structuring projects in RAD and traditional SDLC
So, let’s think more concretely about how projects are structured within traditional SDLC vs RAD. First, we can flesh out the waterfall approach we outlined earlier.
Say for example you wanted to build a new custom CRM for a client.
In the waterfall model, you’d sit down with them and decide everything you need it to do. Once these are agreed upon, you can then move on to designing systems around your specifications, but you can’t go back and change your requirements if something changes.
Each successive phase progresses the same way.
RAD works a little bit differently.
Normally, you’ll start with a more general conversation about your vision for the product, but fall short of a full-on requirements-gathering session. Your developers then go away and build a working version of the tool, either in full or as standalone modules.
Then, all parties come together again to discuss the resulting tools, provide feedback, and decide on changes.
This process can repeat indefinitely until the product is finished. For this reason, RAD is often referred to as an iterative approach to building software. Specifically, the systems design, implementation, and testing phases are continuous and cyclical.
You might also like our guide to building a SQL GUI .
When do companies turn to traditional SDLC or RAD?
So in what circumstances would you use traditional SDLC vs RAD? The reality is that both approaches suit their own unique use cases and goals. This depends on the particulars of what you want to build, as well as the resources available to you.
There are a couple of broad rules of thumb here that we can use to guide us.
These relate to:
- The complexity of the project.
- How mission-critical it is.
- The number of actors involved.
For an extreme example, let’s say you wanted to land a rocket on the moon.
As part of this, you need to build a piece of software to manage your rocket’s trajectory in real-time. Naturally, this requires some complex calculations and extensive integration with external systems.
It’s also totally fundamental to the success of your wider project.
Since the priority is getting everything 100% right the first time, rather than building the tool quickly, traditional SDLC is probably the better option.
Then let’s say you wanted to build single a form for your employees to update their contact details in your various backend systems. There might still be an important business case for such a tool, but it’s unlikely to be a case of life or death.
Technically speaking, it’s also going to be a pretty simple application. At least, compared to rocket science. So, we can afford to focus more on speed, while also prioritizing great user experiences.
Therefore, RAD is a stronger candidate.
Operational issues for software projects
Of course, we need to consider process-level issues too, along with how different development methodologies tie in with your underlying business goals. To be blunt, we want to think about what’s going to make you the most money.
Or, at least, what’ll cost you the least.
Here are the major ops factors you’ll need to consider.
Controlling costs
Direct costs are probably at the front of your mind. Unfortunately, this is one area where it’s quite difficult to make sweeping statements about traditional SDLC vs RAD.
In theory, an effective RAD project should be cheaper than building a similar tool with a waterfall methodology. That is, assuming that you’re using the RAD model in an appropriate context, and everything goes according to plan.
This is a function of the speed that RAD offers. The faster you can bring a solution online, the lower the associated project costs will be.
However, the flip side of this is that development costs are a bit more unpredictable with RAD compared to traditional SDLC. With a waterfall approach, you decide exactly what you’re going to build, then you go away and build it.
By necessity, less of the planning is front-loaded under RAD, so it’s not clear how many iterations you’ll need to build before your solution can be signed-off.
As we’ll see a little later, this can be mitigated to a large extent with the right software stack. Take a look at our guide to business process management .
Stakeholder management
Managing any software project is a serious undertaking, especially when it comes to communicating with non-technical stakeholders. The key thing is being able to give concrete updates on the project’s status.
With traditional SDLC, this is comparatively easy, since your requirements can act as easy-to-understand project milestones.
RAD, however, introduces additional challenges. Since we’re dealing with ongoing, cyclical iterations, it’s harder to say where a project stands at any given moment - let alone how near it is to completion.
Besides this, there’s the issue of conducting feedback sessions. This requires a few extra considerations. On the one hand, there’s the additional labor costs that these meetings bring. On the other, coaxing useful feedback out of stakeholders is a skill in itself.
Check out our guide to throwaway prototyping.
Oversight
Tying in with this is the issue of oversight. As before, the nature of RAD projects means that it can be hard to know exactly where this stands at any given moment. This idea makes a lot of ops professionals very uncomfortable.
There are a couple of levels where this comes into play.
One is simply managing our team. For instance, how are you supposed to delegate work to employees if it’s unclear how long it will take to ship projects? How can you be confident that they’re using their time effectively without clear specifications?
Traditional SDLC offers a higher degree of centralization and oversight, whereas RAD prioritizes speed and flexibility.
Project scope
We can also think about how project scopes are impacted by traditional SDLC vs RAD methodologies. Essentially, a project’s scope is how extensive its features and functionality are going to be, as agreed at the outset.
With traditional SDLC, we agree on detailed requirements at the outset. These don’t really change as the project progresses, so it’s less likely that we’ll encounter scope creep. That is, when stakeholders start requesting new features that weren’t previously agreed.
RAD takes a wholly different perspective.
In some ways, the central idea is recognizing that some amount of scope creep is a fact of life. At least, the basic presupposition is that new requirements will emerge as the project progresses, and traditional SDLC doesn’t reflect this fact.
In reality, there’s a bit of a balancing act that’s needed in either model.
So, we must be conscious of the fact that excessive scope creep can lead to spiraling costs, but inflexibility can inhibit your ability to properly meet users’ real-life needs. We can think back to the kinds of projects that suit each model to help guide us here.
(Proposify )
Traditional SDLC vs RAD: Building a team
It’s also important to distinguish between the kinds of teams that are needed for successful projects within traditional SDLC vs RAD projects. The differences here are starker than you might initially suppose.
Really, we can break this down into three interrelated variables:
- The size of your team.
- It’s structure.
- The specific skills required.
Let’s take a look at each in turn.
Team size
The size of your development team is the easiest factor to get your head around. This is also where the distinctions between traditional SDLC and RAD are most obvious.
One way of looking at this is that RAD works best in small, close-knit teams. In a lot of cases, it might even be a single developer. This goes a long way to managing some of the challenges that come along with rapid app projects.
For one, the issue of communication project changes and updates to different stakeholders. The fewer the actors involved, the easier it is for everyone to be on the same page. This goes a long way to eliminating the risk of miscommunication.
Smaller teams can also move faster. With less administrative burden, reduced need for information sharing, and fewer stakeholders to manage, it’s easier to move from ideation to implementation quickly.
Things work differently under traditional SDLC.
It wouldn’t exactly be true to say that you need a larger team for the waterfall methodology. Rather, you’re more likely to need a more traditional model when you have a larger team.
Say you had 1,000 developers working on a single project.
We need all of their contributions to fit together, but we can’t expect developers to self-manage this. Instead, they’ll need clear expectations, NFRs, and deliverables to ensure that each element works exactly as it’s intended.
Team structure
Then there’s the question of how you structure your development teams. Of course, this ties in neatly with the team size. Bigger teams are generally also more complex. However, there’s no one-size-fits-all approach in either methodology.
So, let’s think about your options for each.
A traditional SDLC project could require an army of developers, system engineers, designers, testers, and project managers to coordinate them all. Within each vertical, you might then have extra layers of specialization or at least more narrowly focused teams.
As we know, each phase of the project must be completed before the next can progress, so project managers are arguably the most important members of the team. Almost all communications and coordination activities will go through the project team.
Therefore, we can think of this as a highly hierarchical structure.
By contrast, RAD teams normally follow a simpler structure. Normally, this is relatively flat, rather than hierarchical. As we know, in the most extreme examples this could be a single developer.
Or, you might have a small team of developers and other functions working closely together.
For instance, one developer and one designer. Your implementation team will also generally have much more say in how the project progresses, as well as direct contact with stakeholders.
Requisite skills
Finally, when considering traditional SDLC vs RAD, we also need to be conscious of the kinds of team members we need. Specifically, we need to think about the particular skills that effective developers need in each.
In traditional SDLC, it’s obviously great if individual developers have an awareness of what happens at other stages of the project, but they only need to know their own piece in-depth. They can just follow the requirements, without necessarily knowing the rationale behind them.
By contrast, RAD involves asking a lot more of our developers.
Any one of them might need to jump between development, design, systems design, QA, and project management tasks. They also need to work much more quickly than in traditional development projects.
In other words, they should be at the absolute top of their game.
Naturally, this creates a few problems. Of course, this costs money. That is, such a skill set doesn’t come cheap. We also need to be able to find and recruit suitable talent in the first place.
Take a look at our guide to empowering citizen developers .
There’s also the opportunity costs associated with other projects that these developers could work on instead of RAD projects.
The key is empowering your developers to do more with less. We want to lower the skills barriers, making it easier for developers to work effectively on RAD projects.
In large part, this comes down to the tools you provide for your team.
Building a software stack
We couldn’t think about traditional SDLC vs RAD without touching on the different platforms that are employed in each framework. You’d be right to expect a degree of distinction here since each methodology has such different priorities and goals.
However, there’s also plenty of overlap.
For instance, the best tools for RAD projects obviously allow developers to build solutions quickly. It would be silly to assume that waterfall-based projects wouldn’t benefit from this too.
This is a topic in itself. Check out our in-depth guide to rapid application development tools for a fuller discussion.
For now, here are the key points.
Development tools
First up, we have the tools that your developers actually build software with. Of course, it gets hard to generalize once we accept that the kinds of solutions they need to build also play a giant role here.
Still, we can identify a few broad trends.
For one thing, traditional SDLC projects are more likely to rely on traditional development techniques. So, hard-coding everything from scratch. This doesn’t mean they’ll only use hard code. Just that this is more common than with RAD.
By contrast, RAD is highly intertwined with low-code development.
This is a match made in heaven since both are focused on outputting relatively simple tools at speed.
Low-code is ideal for RAD because it removes much of the legwork and excessive non-development work from projects. For instance, by making designing interfaces much, much easier.
Of course, this is helpful in waterfall projects too. For instance, if you need to quickly output a working CRUD app as part of a wider system.
Project management
We can identify some broad trends about the kinds of tools needed to project management in each framework too. The core thing here is that project managers often face different challenges in traditional SDLC vs RAD.
In waterfall, we must coordinate activities between different actors, ensuring that all work is delivered on time and to specification. So, we need traditional project management tools, like Kanban boards or other visualizations.
In RAD, we’d normally rely on a slightly different set of tools.
We don’t have as many developers to coordinate. One person might be doing everything, including managing the project. So, what’s important is that we’re able to enforce clear, efficient workflows.
We’d often use bespoke workflow management tools to facilitate this. Check out our ultimate guide to workflow automation for more information on where Budibase comes into play here.
Budibase is a developer’s best friend
At Budibase, we’re on a mission to transform the way businesses build custom solutions. Our open-source, low-code platform is designed to make short work out of all kinds of web app developments.
Tens of thousands of businesses all over the world choose Budibase for RAD and traditional SDLC projects alike.
Connect existing data, autogenerate CRUD screens, build custom components, automate workflows, customize access control, and deploy to your own infrastructure, in one intuitive platform.
We’ve even built over 50 free, deployment-ready app templates to get you started.
Sign up to Budibase for free to start building custom apps the fast, easy way.