Software has always been expensive to produce and purchase. The production of software, or software development, began without any methodology at all. Problem analysis and solution design were accomplished at the same time. The programmer just sat down and started coding. Documentation was typically absent. If a programmer left the firm, along with the programmer went the knowledge of the programs and systems the programmer had created. When programs needed maintenance, the new programmer had to reverse-engineer the code and system before changes could even be made. This approach facilitated rapid application development, but resulted in lengthy and expensive maintenance, and sometimes required starting from scratch when the often modified code became impossible to reverse engineer.
Software developers soon recognized the need for a preliminary analysis, systems analysis and design, and documentation throughout. In the 1960s and 1970s, software development methodologies began to crystallize. By the eighties, the structured software development methodology became preeminent. This methodology called for extensive, up-front planning and design, with top-down analysis and design being the preferred approach. The top-down approach meant that comprehensive planning was required before components could actually be built. Teams of business process designers would map out the overall design of the business system and hand over their requirements to another team of system designers. These designers would specify the detailed parts of a system, drilling down until each part of the system was fully explicated, with narratives and flowcharts for each program. Finally, programmers would code from the documents and produce the programs and systems that had taken months, even years, in some cases, to design. Rapid application development was impossible given all the planning that was required by a top-down approach to systems development.
In the beginning of business computing, businesses were encouraged to automate to remain competitive. Automated sales order systems, for instance, meant you could offer your customers quicker service than your competitors, who still used manual-based systems. As more businesses automated, the flexibility of the system to accommodate changing business requirements became the key to competitive advantage, but the lengthy software development cycles impeded a rapid application development. Often, by the time the systems were completed, new changes in requirements meant the developed system was out of date. A faster approach to software development was needed.
With the rise of object orientated design and development, which tends to create 'reusable' components, components that can be used in more than one system, and the creation of visual software development platforms that made it easy to prototype, a new software development approach emerged, the rapid application development methodology. This methodology emphasizes incremental development, development of programs that facilitated some process that is needed now. Up-front planning and design is not comprehensive, but focused on the problem at hand. Together with the business requirements representative, programmers prototype the required software in little chunks. This allows some functionality to go into production as soon as possible, leaving other functionality for a later pass.
Rapid application development methodology is now mature. Incremental development is putting programs into production much faster than earlier methodologies. The iterative passes are adding the new functionality a changing system requires. Reusable components are being reused rather than rewritten, and software development is able to keep up with changing business requirements at a lesser cost than systems created through other methodologies. Despite this success, most businesses have not adopted rapid application development methodologies. Most businesses prefer to fully scope out a system before they put their programmers to coding it. While this may reduce the risks and increase the likelihood that a
system of programs will exactly meet design specifications, the question of whether the final system will be delivered in time still remains. Once businesses using rapid application development begin to out-perform their competitors who use slower methodologies, rapid application development will begin to enjoy wider use. Only the future will tell.