Relative Effectiveness
The shift from traditional session-based client/server development to open sessionless and collaborative development like Web 2.0 has increased the need for faster iterations through the phases of the software development process. This, coupled with the growing use of open source frameworks and products in core commercial development, has, for many developers, rekindled interest in finding a silver bullet RAD methodology.
Although most RAD methodologies foster software re-use, small team structure and distributed system development, most RAD practitioners recognize that, ultimately, no one “rapid” methodology can provide an order of magnitude improvement over any other development methodology.
All types of RAD have the potential for providing a good framework for faster product development with improved software quality, but successful implementation and benefits often hinge on project type, schedule, software release cycle and corporate culture. It may also be of interest that some of the largest software vendors such as Microsoft and IBM do not extensively use RAD in the development of their flagship products and for the most part, they still rely primarily on traditional waterfall methodologies with some degree of spiraling.
This table contains a high-level summary of some of the major types of RAD and their relative strengths and weaknesses.
| Name | Pros | Cons |
|---|---|---|
| Agile | Minimizes feature creep by developing in short intervals resulting in miniature software projects and releasing the product in mini-increments. | Short iteration may add too little functionality, leading to significant delays in final iterations. Since Agile emphasizes real-time communication (preferably face-to-face), using it is problematic for large multi-team distributed system development. Agile methods produce very little written documentation and require a significant amount of post-project documentation. |
| Extreme | Lowers the cost of changes through quick spirals of new requirements. Most design activity occurs incrementally and on the fly. | Programmers must work in pairs, which is difficult for some people. No up-front “detailed design” occurs, which can result in more redesign effort in the long term. The business champion attached to the project full time can potentially become a single point of failure for the project and a major source of stress for a team. |
| Joint application | Captures the voice of the customer by involving them in the design and development of the application through a series of collaborative workshops called JAD sessions. | The client may create an unrealistic product vision and request extensive gold-plating, leading a team to over- or underdevelop functionality. |
| Lean | Creates minimalist solutions (i.e., needs determine technology) and delivers less functionality earlier; per the policy that 80% today is better than 100% tomorrow. | Product may lose its competitive edge because of insufficient core functionality and may exhibit poor overall quality. |
| RAD | Promotes strong collaborative atmosphere and dynamic gathering of requirements. Business owner actively participates in prototyping, writing test cases and performing unit testing. | Dependence on strong cohesive teams and individual commitment to the project. Decision-making relies on the feature functionality team and a communal decision-making process with lesser degree of centralized project management and engineering authority. |
| Scrum | Improved productivity in teams previously paralyzed by heavy “process”, ability to prioritize work, use of backlog for completing items in a series of short iterations or sprints, daily measured progress and communications. | Reliance on facilitation by a master who may lack the political skills to remove impediments and deliver the sprint goal. Due to reliance on self-organizing teams and rejection of traditional centralized "process control", internal power struggles can paralyze a team. |
Read more about this topic: Rapid Application Development
Famous quotes containing the word relative:
“Personal change, growth, development, identity formation—these tasks that once were thought to belong to childhood and adolescence alone now are recognized as part of adult life as well. Gone is the belief that adulthood is, or ought to be, a time of internal peace and comfort, that growing pains belong only to the young; gone the belief that these are marker events—a job, a mate, a child—through which we will pass into a life of relative ease.”
—Lillian Breslow Rubin (20th century)