A 1986 movie depicts a young boy competing against experienced riders in a high-stakes BMX trick competition to win it all. Rapid Application Development (RAD) is a software development methodology that emphasizes rapid prototyping and minimal planning in order to create usable systems quickly, often within 60-90 days, though sometimes with compromises to cost, quality or completeness. The document outlines the principles, process, benefits and limitations of the RAD approach.

1. A 1986 Movie about a young boy going against the man to win it all in a
BMX trick competition
Rad

2. RAPID APPLICATION
DEVELOPMENT
joel@mediotype.comBy Joel Hart

3. definition
 “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
prototyping.”

4. Ressons to use R.A.D.
 Bad Reasons:
 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)
 Good Reasons:
 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
product quality

5. 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
solution.
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.

6. Problems? With Development Projects?
NEVER!
Problems addressed

7. With conventional methods, there is a long delay before the
customer gets to see any results.

8. With conventional methods, development can take so long that
the
customer's business has fundamentally changed by the time the
system is ready for use.

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

10. RAD USES ITERATIVE, EVOLUTIONARY PROTOTYPING

11. What’s SDLC?
Software Development Lifecycle
R.A.D. SDLC
Development teams must be empowered to make some decisions
traditionally left to management.

12. Step 1
 JAD (Joint Application Development)
MEETING
High-level end-users and designers meet in a
brainstorming
session to generate a rough list of initial
requirements.
• Developers talk and listen
• Customers talk and listen
"Fitness for a business purpose" must be the criterion for
acceptance of deliverables. – Sun Microsystems

13. Step 2
 ITERATE UNTIL DONE
Developers build / evolve prototype based on current
requirements.
 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.
 Developers listen.
 Customers talk.
 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
are dropped.
All constituencies that can impact application requirements must
have representation on the development team throughout the
process.

14. 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
into
operational prototypes.
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
the meeting
 by ensuring that adequate discussion is directed
toward each issue
 by ensuring everyone has an adequate opportunity to
participate
 are followed by a report from the facilitator
Customers, developers and management must accept informal
deliverables.

15. R.A.D. ! But When ???
 RAD TENDS TO WORK WHEN
The application will be run standalone.
Major use can be made of preexisting class
libraries (APIs).
Performance is not critical.
Product distribution will be narrow (in-house or
vertical
market).
Project scope (macro-schedule) is constrained.
Reliability is not critical.
System can be split into several independent
modules.
The product is aimed at a highly specialized IS
(information
systems) market.
The project has strong micro-schedule
constraints (timeboxes).
The required technology is more than a year
old.
 RAD TENDS TO FAIL WHEN
Application must interoperate with existing
programs.
Few plug-in components are available.
Optimal performance is required.
Product development can't take advantage of
high-end IS tools
(e.g., 4GLs).
Product distribution will be wide (horizontal or
mass market).
RAD becomes QADAD (Quick And Dirty
Application Development).
RAD methods are used to build operating
systems (reliability
target too high for RAD), computer games
(performance target
too high for RAD).
Technical risks are high due to use of
"bleeding" edge
technology.
The product is mission- or life-critical.
The system cannot be modularized (defeats
parallelism).

17. Huh? It sounds a lot like Agile!
R.A.D. Is Not Agile

18. 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
completed product.
 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
engineering practices.
 Agile teams are inclusive of testers and analysts and user experience specialists. RAD teams did not traditionally
include non technical team members.

19. What makes the most sense?

20. Well what do I do now?