A 1986 Movie about a young boy going against the man to win it all in a
BMX trick competition
email@example.comBy Joel Hart
“a software development process that allows usable systems to be built
in as little as 60-90 days, often with some compromises”
“a software development methodology that uses minimal planning in favor of rapid
Ressons to use R.A.D.
To prevent cost overruns
(RAD needs a team already
disciplined in cost management)
to prevent runaway schedules
(RAD needs a team already
disciplined in time management)
to converge early toward a design
acceptable to the customer
and feasible for the developers
to limit a project's exposure to the
forces of change
to save development time, possibly
at the expense of economy or
Principals of R.A.D.
In certain situations, a usable 80% solution can be produced in
20% of the time that would have been required to produce a total
In certain situations, the business requirements for a system can
be fully satisfied even if some of its operational requirements
are not satisfied.
In certain situations, the acceptability of a system can be
assessed against the agreed minimum useful set of requirements
rather than all requirements.
Problems? With Development Projects?
With conventional methods, there is a long delay before the
customer gets to see any results.
With conventional methods, development can take so long that
customer's business has fundamentally changed by the time the
system is ready for use.
With conventional methods, there is nothing until 100% of the
process is finished, then 100% of the software is delivered.
Iteration must be used in such a way that the development process
converges toward an acceptable business solution.
Software Development Lifecycle
Development teams must be empowered to make some decisions
traditionally left to management.
JAD (Joint Application Development)
High-level end-users and designers meet in a
session to generate a rough list of initial
• Developers talk and listen
• Customers talk and listen
"Fitness for a business purpose" must be the criterion for
acceptance of deliverables. – Sun Microsystems
ITERATE UNTIL DONE
Developers build / evolve prototype based on current
Designers review the prototype.
Customers try out the prototype, evolve their requirements.
FOCUS GROUP meeting
Customers and developers meet to review product together,
refine requirements, generate change requests.
Requirements and change requests are "timeboxed".
Changes that cannot be accommodated within existing
timeboxes are eliminated.
If necessary to stay "in the box," secondary requirements
All constituencies that can impact application requirements must
have representation on the development team throughout the
Prototyping must incorporate evolving requirements quickly, in
real time, and gain consensus early.
Iterations require between 1 day and 3 weeks.
At some stage, exploratory prototypes may evolve
Focus Group Sessions
last about 2 hours
are led by an experienced facilitator, who keeps the
group "on focus"
by having clear goals regarding the kind of
information that needs to be elicited
by preparing an issue-oriented agenda in advance of
by ensuring that adequate discussion is directed
toward each issue
by ensuring everyone has an adequate opportunity to
are followed by a report from the facilitator
Customers, developers and management must accept informal
R.A.D. ! But When ???
RAD TENDS TO WORK WHEN
The application will be run standalone.
Major use can be made of preexisting class
Performance is not critical.
Product distribution will be narrow (in-house or
Project scope (macro-schedule) is constrained.
Reliability is not critical.
System can be split into several independent
The product is aimed at a highly specialized IS
The project has strong micro-schedule
The required technology is more than a year
RAD TENDS TO FAIL WHEN
Application must interoperate with existing
Few plug-in components are available.
Optimal performance is required.
Product development can't take advantage of
high-end IS tools
Product distribution will be wide (horizontal or
RAD becomes QADAD (Quick And Dirty
RAD methods are used to build operating
target too high for RAD), computer games
too high for RAD).
Technical risks are high due to use of
The product is mission- or life-critical.
The system cannot be modularized (defeats
Huh? It sounds a lot like Agile!
R.A.D. Is Not Agile
10 Reasons R.A.D. != Agile
Agile embraces the concept of contract first development required for either Object Orientated or Service
Orientated architecture – RAD did not acknowledge the realities of designing to interfaces, partially because it
preceded the widespread use of these techniques.
Agile does not allow prototypes – RAD was based on designing prototypes and then reengineering them into
production quality code (or not as was often the case).
Agile projects logically break down the solution into features – the RAD approach did not do this; instead
developers would focus on delivering all the features of the application by first doing it badly and then improving
on the code base overtime..
Agile teams are democratic. This means that the whole team has a say in the architecture of the solution, but the
team is still lead by an architect. In contrast, RAD solutions were not based around the concept of a common
architecture and thus individuals worked in silos.
Agile development team members are self managing. In contrast, RAD teams are managed by a project
manager. Note do not confuse the term management with leadership.
Agile engineering practices (such as test driven development, and continuous integration) are stringent and
thorough, ensuring that problems in the design or the code base are highlighted and fixed as quickly as
possible, and that the team has the confidence to change the code base without breaking the product. None of
these concepts were used in RAD projects.
Agile teams focus on team communication and designing as a group. RAD teams tend to work as
individuals, resulting in unmaintainable and poorly designed code.
Agile teams only demonstrate completed work. RAD teams tend to demonstrate screen mockups, or
prototypes, which lead the product owner to question why they now need to wait another six months for the
Agile teams are based around disciplined individuals that remain continually focused on delivering real software.
RAD teams lack discipline, simply because there was no structure to either the process, architecture or
Agile teams are inclusive of testers and analysts and user experience specialists. RAD teams did not traditionally
include non technical team members.