0740-7459/95/$31.00 © 1995 IEEE
Published by the IEEE Computer Society
Guest Editor's Introduction—The RAD Fad: Is Timing Really Everything
♦ In our haste to speed development, we should consider if we are sprinting in the right direction. Is faster time-to-market equally important to every developer Does a faster cycle time necessarily guarantee success And how does the answer change from one year to the next
The software industry has experienced a series of fads. During the '70s, productivity was the fashionable concern, and a plethora of methods and tools were developed and marketed as productivity aids. During the '80s, quality took center stage, with a similar effect. Time-to-market, rapid development, and related themes may preoccupy the software community by the end of the '90s. This special issue provides articles, opinions, and news that will help the software practitioner understand the nature and potential of rapid application development.
James Martin coined the term "rapid application development" to apply to a specific methodology and toolset. 1
However, the use of RAD has come to imply a wide range of technologies that attempt to reduce development time. Here, I use the term in a generic sense. RAD technologies include time-box scheduling, joint-application-development workshops, application generators, rapid prototyping, and many more. These technologies approach the problem in one of three ways: performing activities concurrently, avoiding some activities entirely, or delivering capability incrementally. Simply "working faster" is wishful thinking, not a meaningful solution.
It is important to distinguish between time-to-market and software-development cycle time. Time-to-market is the time elapsed from project initiation to the first product's delivery to customers. The product may be more than just software. Moreover, the time to market is sure to be affected by factors other than the software process. The software-development cycle time is the amount of time it takes to produce a fixed quantity of software. This is different from the common tactic of negotiating the amount of capability to be delivered to fit within a fixed schedule. In this issue, Neil Olsen provides a high-level model of cycle time, and the article by Farshad Rafii and Sam Perkins illustrates the difference between cycle time and time-to-market. Rafii describes a business that, although it reduced its time-to-market through concurrent development, did not significantly change the cycle times of the individual software processes.
Cycle-time reductions are most often obtained by eliminating or automating activities such as rework, coding, and documentation. Incremental development approaches may be adopted to allow more concurrency within a software process. Incremental and prototyping approaches may reduce time-to-market by getting some partial capability into the customer's hands early. In this issue, Emmanuel Henry and Benoît Faller show how software reuse (avoiding code development) significantly reduces cycle time.
Is RAD just a passing fad To answer that question, it helps to examine earlier fads. The productivity and quality initiatives of the '70s and '80s did contribute to some successes, but they have also led to visible failures. These failures are usually blamed on poor technology, poor implementation of the technology, and poor management. Indeed, many software engineers are already pointing out the importance of effectively managing RAD. 2
However, a more fundamental problem is the potential mismatch between the technological fad and the needs of business. Businesses must consider whether or not there is a match at both the strategic and tactical levels. Does an organization really need the benefits the new fad promises Of course it is always good and desirable to reduce cost, increase quality, and shorten time-to-market – but are they equally important to everyone's success
At the strategic level, a business should consider the importance of time-to-market to its success. Figure 1
shows two factors that shape markets: the number of consumers and the number of suppliers. These two factors define four markets, each of which require a long-term business strategy:
Figure 1.. The number of consumers and suppliers defines four markets, each of which requires a different long-term business strategy.
♦ Capability. Most markets begin with relatively few producers and consumers. In this type of market, capability is the most important business factor — offering something the competition doesn't. Early adopters of new products are often willing to pay more and accept lower quality than the normal customer.
♦ Cost. In a market with relatively few consumers and many suppliers, consumers dictate the capability, quality, and schedule they desire. The suppliers' only possible business strategy is to meet those requirements at the lowest cost.
♦ Time-to-market. In a market in which only a few producers compete for many customers, the business that gets its product out first will capture a large part of the market. Generally, the competitors are well-known to each other.
♦ Quality. In a fully mature market with many suppliers and consumers, quality is a primary determinant of success. It is difficult to get to market first because there are too many competitors to track and stay ahead of. It is difficult to have the lowest cost, because someone else can always run a sale. Because these markets are mature, the potential capabilities of the products are well-understood — truly revolutionary advances are unlikely, and when they occur they often create a new market.
CUSTOMIZE YOUR INVESTMENTS.
To get the best return, businesses should invest in technology that will give them a competitive advantage within their market. Markets change, so business strategies must change to keep pace. It is common for time- and cost-sensitive markets to change to quality-sensitive markets as more consumers and suppliers enter. An organization that invests in technology that supports a business strategy for a market as it existed a few years ago probably won't gain a competitive advantage. Of course, focusing on only the primary strategy and ignoring all others can also lead to disaster. Ed Yourdon suggests that the current fad has made quality an inflexible ideal, when careful tradeoffs of capability, cost, schedule, and quality should be considered. 3
Obviously, the simple model in Figure 1
does not capture all the market factors that affect business strategy, but it illustrates the point that there are markets in which time-to-market is critical and others in which it is less so. Nevertheless, a recognition that there are significant markets in which productivity and quality are not paramount motivates the current interest in RAD. This segment of the software market has not previously been the focus of attention by researchers, methodologists, and tool vendors.
At the tactical level, the decision to invest in a specific RAD technology must be based on a detailed understanding of the business's processes. "Rapid" techniques do not always reduce cycle time or time-to-market. For example, a survey of 39 rapid-prototyping projects did not report any instance of schedule reduction. 4
Achieving a significant schedule reduction requires first understanding where delays are occurring and then applying technology to address those specific problems, not just adopting a generic set of "accelerated" methods and tools. The delays in delivering software to market may have nothing to do with software. For example, the requirements-definition and acquisition phases of many government software projects often exceed the development phase.
What this discussion shows is that RAD responds to a real need of businesses competing in time-sensitive markets, but that its adoption by others will probably have a limited effect. The RAD fad will help some businesses, but many others will be disappointed. Nevertheless, RAD technology does offer new help to those businesses competing in a type of market that has previously been largely ignored — the market in which getting there first is everything.
David N. Card is a principal software engineer at Software Productivity Solutions, where he provides consulting services to businesses and governments. He spent 15 years at Computer Sciences Corp., where he supported the NASA Software-Engineering Laboratory and served as a resident affiliate at the Software Engineering Institute. He has authored more than 20 articles and one book, is an associate editor of Journal of Systems and Software, and he serves on Information and Software Technology's editorial advisory board.
Card received an interdisciplinary BS from American University. He is a member of the IEEE Computer Society and the American Society for Quality Control.
Address questions about this issue to Card at SPS, PO Box 361697, Melbourne, FL 32936; firstname.lastname@example.org.